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

[Sam Vilain]

On Tue, 2005-10-25 at 00:54 -0400, John Siracusa wrote:
> On 10/25/05 12:33 AM, Sam Vilain wrote:
> > On Fri, 2005-10-21 at 08:25 -0400, John Siracusa wrote:
> >> 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.)
> > 
> > And avoiding all that mucking about is precisely why you'd want to use
> > an orthogonal storage system that doesn't intrude to your classes, and
> > supports demand loading.
> 
> Er...what?

Well, in a sense, if you use Tangram that abstraction is already right
there.

"Orthogonal" literally means "perpendicular to", or "completely
unrelated to".  So what is an "orthogonal storage system" ?  One that
doesn't interfere with your application's objects.

"Demand Loading" means that when you try to follow a reference that is
not already "hot", the storage system traps that access, performs the
load and then puts the data in place.

The "database objects" exist (for a short while), but are converted into
your application objects, which do not have to have anything special in
their @ISA, or support any special methods, or have any special fields.
There is a little magic used for this to work flawlessly, but nothing
that isn't stock standard Perl these days.  So you have complete control
over how the objects behave in your application, and if you don't pass a
storage handle in (and the objects aren't cached, and no read triggers
modify the database etc), you can't change the persistent state of the
objects.

The pattern you describe (which I'd probably call a "facade") is then
rarely necessary.

Sam.