Monday, May 26, 2014
On Sunday, May 25, 2014 1:40:40 PM UTC-4, Ruby-Forum.com User wrote:
Thanks a lot for the detailed explanations. Two remarks for this:
As for the naming, my application evolves a dictionary of foreign
language idioms, and the main purpose it to train the user in the usage
of these idioms. From the perspective of the user, there are 3 types of
"screens" (HTML pages):
- The login page (where he identifies himself, chooses (or create) a
dictionary)
- The Management page (where he can import/export dictionaries to/from
database, merge other dictionaries into the existing ones, add new
idioms (this is really an "edit" action) and, most important of all,
select one of several training plans and start trainig).
- The Training page, where an idiom training is performed on the fly.
This page also allows, for convenience, editing vocabulary on the fly
(but only the one which is presented right now).
From this setup, I found that the usual CRUD actions don't go that well
with the application, and that's why I invented the action "manage" in
dict, and in the meanwhile the action "start" in the (new)
training_controller. However I am flexible with names, and if an
experienced Rails developer strongly suggests going with standard action
names, I certainly don't object. After all, I can still keep the "meat"
of my code in my "manage" routine, and just have the "edit" method call
"manage()".
As for "generate scaffold", I have used this when doing exercises back
with good old Rails 1, but now with Rails 4, the tutorial doesn't use
"generate scaffold" anymore, but always "generate model" and "generate
controller". Do you recommend me to investigate into "generate scaffold"
too?
Thanks a lot for your detailed comment. It really helps a lot!
One final question: I have read various tutorials, but when it comes to
look up the API, I found the documentation a bit confusing, and
difficult to find what I am looking for. You gave for example a
suggestion to use the "resources" method with the path_names: parameter.
Though I have stumbled several times over the usage of 'resources', I
haven't found a single place, which would explain the usage of all
parameters (such as path_names:) and examples of usage. Right now, when
I really want to know how something is done in Rails, I google for it,
hoping that someone else had the same problem. This often works out, but
I would be more happy if I had a documentation of the Rails classes and
methods, in a similar way as it is for Ruby and the standard functions
and -classes. Is this available, or is Rails in the flux so much that we
can't expect this yet?
--
Posted via http://www.ruby-forum.com/.
OK, this gives me some more information, but I'm still not completely sure I understand the application. It sounds like a given user can have one (or more?) dictionaries associated with the user and that each dictionary has one or (probably) many idioms associated with it. In this case, dict is a resource. If I read this right, in your initial application a user could create a dictionary. I'm assuming that you may, in later development, have the option to edit a dictionary (which is different from editing an idiom), or delete a dictionary. However, you also have elements such as import and export that are not standard CRUD actions. You've included them in an action manage, but I have a feeling that import and export may be also be separate actions. I'm making some assumptions here which I frequently have to do when answering posts on this list, and if I've assumed incorrectly, that will affect my answer.
In that case, you would need to extend the resource to include actions in addition to the standard new, create, edit, update, show, index, and destroy actions. In this case, let's assume we want to add the action manage. You would do that as follows:
resources :dicts do
member do
get :manage
end
end
This differs from path_names. path_names changes the name of the path but does not otherwise affect the routing or actions associated with the resource. The above code adds manage as a separate action, and creates the appropriate routing and named paths to go with it.
With respect to the scaffold generator, yes, I believe it is worth using, but there are developers that would disagree and don't use it. Some of the tutorials, such as the railstutorial.org tutorial that is commonly referenced on this list, have you use the controller generator and model generator so that you learn the concepts involved by being forced to manually create a lot of the elements. I believe this is appropriate and a good approach for a tutorial. Likewise, the same tutorial takes you through the steps of manually creating a user resource and authentication. Again, you should, IMO, understand these concepts. However, there are are some ways to make your development more efficient once you have mastered these concepts. The scaffold is one of them. Typically, I start with a scaffold and generally modify it to fit the particular needs of that resource. Likewise, I don't usually (never) roll my own authentication, I use the Devise gem.
With respect to documentation, it is true, Rails changes quickly (IMO, mostly for the better) and sometimes the documentation will lag a bit. I believe, in general, the Edge Guides are well done and would recommend them. There are a few cases where they may not be as comprehensive as you might need. There is one other resource I would recommend. The Rails 4 Way is a book you can buy from leanpub.com. I don't have any connection to the book or that site, but if you buy it from them, you automatically get any updates to the book and they update fairly regularly. This is, IMO, an excellent reference. I would not use it to learn Rails basics. It's fairly advanced and would not be appropriate until you have mastered the basics through a tutorial, but it covers the topics you asked about better than any other resource I know of. Hopefully, others have some input here as I'm sure there are resources I'm not aware of. The Railscasts are also good, but I'm not sure if they're being maintained and updated at the moment.
The classes and methods themselves are documented in the Rails API (api.rubyonrails.org). For example, at api.rubyonrails.org/classes/ActionView/Helpers/Urlhelper.html you will see all the methods and options for button_to, link_to, mail_to, etc. that you use in view rendering.
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/f3246535-f3ef-47d3-9650-55a3267c2d85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment