On Tuesday, May 27, 2014 2:36:53 AM UTC-4, Ruby-Forum.com User wrote: > > You did grasp the concept of my application amazingly well, only that > the only possible ways to "edit" a dict is to add and remove idioms > (would you see this as editing the dictionary, or as manipulating the > Idiom class?). > > The reason why I did not follow the CRUD way - and maybe this I was > mislead here - was the following: > > When starting the design, I started with a concept of the screens the > user is going to see. The initial screen will present an entry form for > the name of the dictionary, the user name, buttons for creating and > opening a dictionary, and - for the creation case - an entry field > denoting a dictionary type (think about it as the "language" for the > dictionary, but the concept is more general). > > After clicking one of the buttons, a new screen appears from where the > user can click various buttons - exporting the dictionary, start one of > three predefined training types, manually adding idioms to the > dictionary (but on this screen no possibility of deleting or editing > idioms, nor for the deletion of the dictionary). > > My idea was that the logic for each web page should correspond to one > controller method. In this case, I have used two different controllers: > For the entry page I have a login_controller (because I would like to > add password authentification later on), and for the second form I have > a dict_controller. > > Similarily, I am planning a training_controller for doing the idiom > training, and another controller (maybe idiom_controller) for adding, > deleting and editing individual idioms. > > Maybe this mapping "web page" to "controller" is, from the onset, bad > design? > > -- > Posted via http://www.ruby-forum.com/. >
Web pages would be more likely to map to a controller action, not to a controller. It's common to start by laying out your web pages and then working back from there. However, I'll warn you it's usually a back and forth process. Once you have the web pages laid out, you need to establish a structure that usually involves grouping pages to controllers that follow Rails conventions. In this case, you have at least three resources: user, dict, and idiom. You ultimately will most likely have more. I would recommend you go through the tutorial at railstutorial.org because it does a very good job of introducing these concepts and you will really need to understand this when you introduce password authentication. Editing a dict resource would not be adding and removing idioms, that would be the create and destroy actions of the idiom resource. Editing a dict resource would involve renaming the dictionary or changing the dictionary type. Rails comes with a default set of actions related to a resource but you don't have to use all of them. It's also not a perfect science. A good example is your training screens. That might be its own resource, it might just be an extension of the idiom resource, or it could be its own controller but not correspond to a resource. It depends on how much functionality there is. Not everything will fit into a resource. For example, many applications have static pages such as a home page, an "about us" page, etc. I usually group those into a pages controller which stands on its own, it has no resource or model behind it. Again, the tutorial will do a much better job of explaining this. -- 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+unsubscr...@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/7dd12d77-3f72-4620-bc84-1398a7e01a44%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
