xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <m...@sergeant.org>
Subject SiLLy (was Re: [RT] Rationalizing XSP (was: XSP and aspects))
Date Mon, 05 Mar 2001 10:37:48 GMT
On Fri, 2 Mar 2001, Ricardo Rocha wrote:

> 5) Defining a logicsheet language: SiLLy
>    NB: Logichseets are far simpler in AxKit (Perl). Boy, are they lucky!

Yup :-)

Actually someone has also submitted a taglib module that allows you to
just write a Perl class, and all its methods are turned into taglibs. That
will probably be included in the next release of AxKit.

> XSLT-based XSP logichseet authoring has turned out to be a true PITA
> (tm).

Well I actually don't claim that SAX based code generation is much easier
- its more that Perl code is shorter generally, so it looks easier. But
SAX presents its own set of problems that we have to deal with.

> XSLT is _incredibly_ powerful, despite the claims of those who only seem
> to understand procedural transformations (cousins of the ones advocating
> the infamous <xsl:script> tag which, btw, I've seen only in M$'s
> implementation)
>   OT: There has been a controversy about XSP vs XSLT extensions. The new
>       controversy about XSLT vs XQuery promises to be enlightening in
>       this regard: while nobody wants redundancy, I also wonder whether
>       there's a "one size fits all" attitude. A juicy subject, indeed,
>       but that deserves a separate discussion...
> Powerful as XSLT is, its use in code-generation logicsheets doesn't come
> without problems.
> Granted, most transformational patterns characteristic of code
> generation
> can be correctly and completely expressed in XSLT without resorting to
> extension functions (wich, btw, are currently available only in Xalan).
> Their implementation, though, is usually too verbose and convoluted.
> To illustrate the point, remember how one must declare dynamic tag
> parameters so that they can be referenced as XSLT variables in source
> code templates: tedious, repetitive, error-prone.
> String manipulation is also a problem area. Think of the complexity seen
> in the "get-nested-string" utility template.

Plus you guys need to stop including that code in every logicsheet. The
re-use police will get you.

> Indentation in generated code is also a problem. While, for most
> languages, this is just an aesthetic consideration, there are other
> cases in which it can become a real problem: think of [J]Python.

I'd rather not :-D

> A higher level language is called for and we all have known it for a
> while now. That's what SiLLy is about.

[SiLLy stuff snipped]

While I think SiLLy could probably work well for you, I want to avoid
thinking that it can be cross-language. It can't. But if AxKit decided to
run with SiLLy (I'm still quite undecided), then I guess it could be a lot
simpler to go from Java to Perl, but then again the object model is
completely different, so I doubt it would be that easy.

I think the best thing SiLLy has going for it is that it could potentially
make documenting taglibs a lot easier. This is somewhere I've noticed that
Cocoon is really weak at in comparison to the AxKit taglibs - all the core
AxKit taglibs are well documented, whereas I don't think you guys yet have
docs for Util, sendmail, etc (not that I've found anyway). The reason
AxKit's taglibs are well documented is that we use Perl (SAX) to make our
taglibs, so we have POD available to us for documenting them.


    /||    ** Founder and CTO  **  **   http://axkit.com/     **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** mod_perl news and resources: http://take23.org  **
    //  \\

View raw message