This is going to be of interest to programmers of the Lucky web framework and Ruby on Rails (which is the source of many of its ideas).
The Lucky framework exceeds Ruby on Rails (RoR) in breaking up everything concerning a data class into little files. Generally this is done for good reasons. Keeping all of your actions for a data class in one file, as RoR generally does, makes generating new actions impossible after the user has first edited an action file. So, Lucky splits them. Unlike RoR, Lucky splits model objects into three classes. As generated and using the stated conventions for the Lucky framework, a
User model with a
Users::Create action would have a
UsersQuery query class, a
UsersCreateForm and a
This gets in the way if one wishes to create standard templates for things. A typical action making use of all of the necessary objects (with the rest of the necessary code hoisted into our
do_create() method of BrowserAction), might look like this:
class Manufacturers::Create < BrowserAction action do do_create(ManufacturersCreateForm, ManufacturersNewPage) end end
However, we could easily do away with the excessive number of unique class names in this action, using a little renaming. Consider that we could rename the forms and pages to Manufacturers::CreateForm and Manufacturers::NewPage. The action then looks like this:
class Manufacturers::Create < BrowserAction action do do_create(CreateForm, NewPage) end end
The Crystal and Lucky solution to this issue so far is to use macros, so that the un-orthagonal class names are dealt with by string transformation rather than the type system as above. The problem with this is that macros make it more difficult to understand what is actually happening in your code, and emit more cryptic debugging output than methods and functions when an error is triggered within them. A downside of macros in addition is that they appear exactly as functions or methods to the naive programmer, however they take textual parameters rather than variable parameters. This propagates through a program: if you want to pass a parameterized argument to a macro rather than a textual constant, the caller must itself be a macro.
Using the type system to disambiguate these objects is a cleaner, less verbose, and more easy to understand solution.
Let’s consider models and queries. A
User model has a UsersQuery class for its queries. This follows a RoR tradition to pluralize everything to do with a data object other than the object name itself. I submit that this should be called User::Query. Further discarding the pluralization we would have a User::Create action, a User::CreateForm, and a User::CreatePage. And action URLs like /users/new would become /user/new .
The existing style choices reflect a perception that models define a singular record and all other activities deal with plural records. They are not strictly necessary to either the Lucky or RoR framework, one can rather laboriously rename directories and filenames and edit class names. They are entirely stylistic and it does not particularly contribute to programmer or user understanding that these things are pluralized. Indeed, it is one more convention to be learned.
Lucky can, and should, depart from Rails conventions where they can be improved. Thus, I propose that the programming convention and default grenerated code place everything that has to do with a User model under User::, giving us object names like User, User::Query, User::New (action), User::NewPage, User::CreateForm.
For now, I’ll simply manually edit my code so that it operates this way. Please don’t change the framework in a way that would break this.