While I don't have an answer to your question I have some thoughts and a suggestion.
Putting this knowledge of the display of the data into the model seems to be a violation of MVC in a big, big way. Although I'm not sure if you care ;-) I was faced with some similar challenges and began using munger[1] - it was a good find. It gave me the flexibility I needed to format data for display in a variety of ways while keeping things separated. From your brief explanation it seems like this might help you out. Hope you get things going no matter how you decide to proceed. Don [1] http://github.com/schacon/munger (and my fork http://github.com/elskwid/munger) On Jun 22, 2010, at 2:31 PM, Dave Howell wrote: > I've spent a couple hours prowling through Sequels source code trying to > figure out how to accomplish this. In the process, I've become really really > impressed with Sequel. Wow, there's a phenomenal amount of flexibility in > there. > > *** > > I've figured out that all the various templating engines for converting > regular Ruby stuff into HTML for web pages are going to be 'too little too > late' for me, and I'm moving to building the entire page dynamically in my > controller. I've created a couple of new methods on String to make that a bit > easier. "Something or other".to_html(:p) becomes "<p>Something or > other</p>", for example. I also have a .to_link method: > myProductDataset.collect {|product| > product.name.to_link("?id=#{product.pk}")} > > I think I can clean things up a lot more, though, with a slightly different > approach. I'd like to teach Sequel::Model to take over a lot of the work of > making db data HTML-ready. > It would use a subclass of String (call it WebString) that Sequel::Model > would use as the base type for all the string values. WebString would have > .to_html and .to_link methods, where .to_link automatically creates a link > tag based on the primary key of its model. (I'll probably switch from > directly using the model's primary key to using some kind of session-specific > id code at some point.) > > > My ultimate vision goes something like this: > I build a dataset just like usual. I tell it that stuff in the second > column should have its .to_html method overridden with .to_link. I add the > dataset to an array or other output collector. My work is now done. When > it's time to create the view, my output routine checks for objects that > respond to .to_html, and calls it if they do. The dataset itself responds to > .to_html by building a table (or maybe it uses nested DIV tags, or whatever), > and in turn calls .to_html or .to_s on its rows, which in turn calls .to_html > on the fields. The final result is an HTML table with one column containing > hyperlinks to single item pages. > > I suspect at some point .to_html will decompose to XML objects rather than > directly to plain strings. But I know the first step is to upgrade the > functionality of my dataset output objects. > I *think* this can be done by creating a plug-in and overriding some existing > methods. However, I haven't yet been able to figure out *what,* exactly, I > should consider overriding to do this. Can anybody give me some suggestions > as to where to look? > > -- > You received this message because you are subscribed to the Google Groups > "sequel-talk" 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/sequel-talk?hl=en. > -- You received this message because you are subscribed to the Google Groups "sequel-talk" 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/sequel-talk?hl=en.
