OT: Templating systems (was RE: [Catalyst] New default screen for Catalyst)

[Matt S Trout]

On Fri, Oct 21, 2005 at 08:25:58AM -0400, John Siracusa wrote:
> On 10/21/05 12:27 AM, Perrin Harkins wrote:
> > John Siracusa wrote:
> >> Er, call me crazy, but I don't want my views doing selects either.  As far
> >> as I'm concerned, the only think a template is allowed to do is rearrange
> >> the data I pass it and synthesize values based on that data.  No selects, no
> >> db access at all.  How do I enforce it?  Er, code reviews, I guess :)
> > 
> > What, Rose::DB::Object doesn't do lazy-loading? :) I think that's the
> > sort of select that Bill was talking about.
> > 
> > We had a discussion about using callbacks vs. getting the data up front
> > on the TT list a while ago.  The thread is here if anyone is interested:
> > http://template-toolkit.org/pipermail/templates/2002-April/003119.html
> > 
> > I'm not entirely decided about this.  In theory I think it's probably
> > better to get the data up front, but passing Class::DBI objects to a TT
> > template is so easy that it's just about irresistible.
> 
> As I replied to Bill off-list, I don't pass hashes or arrays of data to
> views, nor do I pass db objects.  I pass a form object, which is already
> populated with all the info I need.  (Rarely will the view also need the
> associated db object, but if it does I can pass that too.)  So I'm firmly in
> the "get the data up front" camp :)
> 
> The flow is like this:
> 
>     1. Instantiate and load the db object.
>     2. Initialize the form object with the db object.
>     3. Pass the form object to the view
>        (and maybe the db object too, but usually not.)
>     4. The view asks the form object to render its fields
>        (or pieces of fields, or passes the fields or form object
>        onto other sub-views, etc. etc.)

Somebody at this stage should probably point out Rose::HTML::Object as
what you're (presumably) using to do this. Any disagreements I might have
on ORM design aside, the Rose::HTML::Object form stuff is very, very cool
and well worth a look.

Incidentally, does the RHTMLO form code need any co-operation from the
ORM? If so, I'll add making DBIx::Class provide such to my list of stuff
to get round to ...

-- 
     Matt S Trout       Specialists in perl consulting, web development, and
  Technical Director    UNIX/Linux systems architecture and automation. Mail
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +