Re: Templating Solutions

[Steve Purkis]

David Cantrell wrote:
> 
> On Tue, Jun 19, 2001 at 10:20:37AM +0100, Steve Purkis wrote:
> > David Cantrell wrote:
> >                                                   of course the line
> > will never be 100% clear & cut-out...  And as for inventing new wheels -
> > well we're all coders & scientists & engineers here...  That's what we
> > do!
> 
> Well yeah, and it's fun too, but in this case the new wheel is not
> necessary.  And if I'm building this for your company, I think you'd
> rather I spent time writing a kick-ass application (which would of
> course be maintainable, extensible, scalable and all sorts of other
> laudable -ables) rather than spending the same amount of time writing
> a kick-ass mini-language (or learning someone else's mini-language)
> and a mediocre app.

Agreed (though, people will sneak things like this in anyway!).  But I
think if you can convince your boss that spending 1 mo developing a
templating system (or any set of tools, really) that you believe will
increase your productivity by a large %, then you should go for it.  But
I stipulate: only if there's a valid business reason.  And it's all the
researching into what other people have done that really takes time.

(as an aside: Maybe there's a real need for evaluation of modules /
systems here which CPAN doesn't [can't?] cover...  If I say something
like `Certified', how many flames will I get? ;-)


> > I see where you're coming from, but think about how this will be abused
> > - coders will get lazy and eventually just embed all the business logic
> > in the templates.
> 
> Yes, they will.  Unless you have proper procedures in place to prevent
> it.  Luckily, perl makes it rather easy to encapsulate application logic
> elsewhere.


Unfortunately, Perl's flexibility also makes it hard to develop
procedures for ;-)


> > I'd argue that embedding code in your templates is on the way out, and
> > the sooner it goes the better.
> 
> So how do you think it can be achieved?

Mmm.  Might have to re-phrase that - "... embedding *native* code in
your templates ...".  So I'm saying asp, jsp, etc.. are good attempts,
but at opposite ends of the spectrum.  We need a more central solution.

So to answer your question... (Steve gulps at the risk of being shot for
not reading the rest of this thread...):

In general, I think tools like TT are going down the right path.
But I think that, ultimately, this problem can be solved by introducing
a simple java/ECMA-script like language into the ``html'' layer purely
for presentation logic and access to application data.  The language and
how the application feeds data into the Somethin-script datastructures
would have to be spec'd outside of Perl (for obvious reasons - it's not
Perl!).  Combine this in some fashion with XSL and you've got yourself a
generic [perhaps over generic?] way of delivering what marketeers like
to call dynamic content.

The quick alternative to this is to build javascript data structures
with your application & use JS in combination with DHTML to generate the
pages clientside.  (disclaimer: i may have been on crack when i wrote
this ;-)

Anyway, if you combine the scripting idea with something that's been
kicking around in my head for the past year - namely that Perl needs a
good `Application Server' in order to compete in the high end of the
market - then you've got some more `ground breaking technology' (read:
SuperCoolWheel v3.0! ;) for the Marketeers to yabber on about, and
potentially a useful set of tools for us developers.

Of course, as you point out above, who in their right mind would pay for
a new wheel when you could be making your company money instead?  Even
though there's a potentially *huge* market for this, that's still one
problem I can't solve.

regards,
--
 Steve Purkis      [EMAIL PROTECTED]     t: +44 (0) 207 614 8600
 Unix Developer      red | hot | chilli         f: +44 (0) 207 614 8601