> > I would think this is the kind of application where you would want
"deeper"
> > pipelines... In other words you could have 2 levels of XSP processing,
the
> > first level can deal with taglib x, and the 2nd can deal with taglib y.
In
> > many cases you can simply use 2 namespaces and combined functionality of
> > several taglibs, but there are cases like PerForm where that may not be
a
> > good solution, so hence deeper pipelines, maybe even something like
XSP ->
> > XSLT -> more XSP -> more XSLT...
>
> Ugh, SAX based is faster and cleaner. IMHO, of course. SAX based taglib
> combining is done in parallel, compiled, and just plain works. The code is
> simple. Really simple.
I disagree. I think this is another example of procedural vs. functional
programming. XSLT is a functional langauge, Perl is procedural. I would
much rather componentize my work in small, re-usable chunks, and to hell
with performance. My time is more valuable than an extra server or two.
So, I would like to have an XSP page describe, for instance, the structure
of a form. Then, have an XSL stylesheet process that form to do the grunt
work of setting up the validation rules, database accesses, etc. The XSL
stylesheet could then output another XSP page which handles the actual form
(which is displayed by a final XSL stylesheet). Want to have repeatable
elements in your input form? Its just an extra parameter to the XSL
stylesheet and a @repeatable="true" in your first XSP page, and it adds more
validation code for that field. It would save me quite a bit of time, and
is still clean (XSLT is a lot easier than
$this->is->{a_really}->long->object).
Therefore, I think this way of doing things is still valid. Is there any
way of implementing this? (I don't see why not, except the Perl code from
the second XSP page couldn't be cached).
-man
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
