[ic] Decision tree for using Embedded PERL versus ITL

Brian J. Miller wiggins at danconia.org
Wed Jul 8 16:58:29 UTC 2009

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,

[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)

... 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.
brian at endpoint.com

More information about the interchange-users mailing list