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
