On Feb 22, 2011, at 5:11 AM, Paul-Michael Agapow wrote: > A question about the right design/approach for solving a particular problem > in Hobo: > > We're using Hobo to put together epi-informatic (disease data) websites and > for the most part it's been a great success: 80% of the task is quickly > building sites for secure access to and updating of validated databases. > Quick, fast, works well, awesome. > > Where things get harder is that we have to provide several specialised tools > and forms for users to manipulate and visualise the data. For the most part > these tools don't associate well with individual models and trying to force > them into that idiom is awkward. (A statement that applies double if you look > at vanilla Rails.) So what's the best way to build in a number of non/multi > model forms? Approaches I've tried: > > * Make tools as new actions on models: as said, many of the tools are > non/multi model so this is awkward. It also scatters all the tools to > different places across the site. Messy. > > * Make a "tools" model. Inelegant, but this way we get full Hobo access > control and DRYML. On the other hand, it requires different Tool > objects/pages to somehow point to different tools (services), and hacking the > show method of the controller to handle form submission and operations. And > there's a useless table in the database. Again, inelegant. > > * Make a tableless model for the tool: means we don't hit the database, but > has the disadvantages of the above approach. Also, there's a lot of > boilerplate written trying to subvert the the model machinery, rather than > solving the problem. > > * Use a raw Rails controller: means we don't get anything "for free", make > only light use of DRYML. Security isn't as nice as in Hobo either. This is > where I am at the moment and it feels like hard work compared to the rest of > the site.
What about the option missing from the above - make a hobo_controller instead of a hobo_model_controller. For instance, the generated FrontController is one of these. You still have most of the authentication support, but without mucking around with dummy models. For instance, this search is implemented as a hobo_controller: http://www.oab.org/search The results are a hodgepodge of different resource types, so it makes sense to not have the action attached to a particular model. You don't get auto_actions and friends in this situation, but I suspect the controller actions are going to be hand-written in any case. To set up the initial context for DRYML, you can either put this in a view: <do with="&@some_instance_variable"> ... </do> or you can set @this in the controller action, which will accomplish the same thing. --Matt Jones -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.
