[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