[ic] Decision tree for using Embedded PERL versus ITL

[Brian J. Miller]

Marty Tennison wrote:
> OK all you interchange gurus out there, riddle me this...
> 
> What criteria do you use to determine whether or not to use embedded 
> PERL or ITL?
> 
> As an extreme example: If an interchange Guru (pick one from the list) 
> was to create their "Perfect" catalog that only they would maintain and 
> hack on, would they use embedded PERL only?  ITL only? or a mixture of 
> both.  And why? Just curious. :)
> 

ITL only *for the views* (or neither, if you wanted to use a different 
view language for instance).

I've built a number of applications that use absolutely no embedded 
Perl, and use only a *very* minimal ITL set. If you take advantage of 
ActionMaps and FormActions then you can reduce the "page" to a "view 
only" and if you properly set up all context needed by that view within 
the AM/FA and store it to scratch then you can get away with using only 
minimal templating tags, such as,

[output]/[unpack]
[if/else/etc.]
[scratch/tmp]
[loop]
[query] (we actually use a custom "delayed-query" tag that allows you to 
do a list=`` like with [loop] but with pagination)
(and sub-query tags)
[include]
[cgi]
[value]

... and some variables (such as the templates/regions).

This provides a nice separation of concerns while providing for a test 
path by moving all business logic into Perl stored in libraries that can 
be tested with TAP (i.e. Test::More). Throw in an ORM that you use as 
your interface from within the AM/FA and you are two thirds of the way 
to an MVC architecture. Add a bit of wrapper goodness to your call 
structure for the AM/FAs and you have your final 1/3. To come full 
circle, if you upshift your execution to an Autoload, then swamping out 
the view language becomes even more trivial.

-- 
Brian J. Miller
End Point Corp.
http://www.endpoint.com/
brian at endpoint.com