cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: Comments on XSP 1.1 (long)
Date Tue, 31 Oct 2000 18:42:04 GMT
Matt Sergeant wrote:

> SiLLy is for logicsheet/taglib authors. These people are programmers. I
> don't really see how it makes sense to ask them to work in XML for
> defining their API. Logic is language dependant (no matter how you turn it
> around), so why not let them use their language to define these things? I
> guess I just don't see the benefit between what you have below, and the
> following XPathScript logicsheet which does almost the same thing but in
> Perl:
> <%
> set_namespace( util => 'uri' );
> use Time::Object;
> $t->{'util:system-time'}{testcode} = sub {
>         my ($node, $t) = @_;
>         $t->{pre} = '<xsp:expr>localtime->strftime(' .
>                 $node->getAttribute('format') .
>                 ')</xsp:expr>';
>         return 1;
> };
> %>

XSP code generation is XML-based: a number of successive transformations
are applied to the XSP document as to render a final, compilable/
executable source program that can rebuild the original document (as
augmented by embedded dynamic tags)

The API and the logicsheet are _separate_ entities. The API should not
be aware of its usage in an XSP context. Logicsheets provide a clean,
simple way of mapping dynamic tags to their corresponding API

This separation is convenient: it allows, for instance, for separate
development and debugging of reusable logic. Such logic should not
be tied to its use in an XML context (think of EJB's).

The "religion" implicit in SiLLy is that business logic is designed,
written and tested separatedly from the [XSP] application. All that
logicsheets provide is a simple way of mapping dynamic tags to method
calls for a given API.

Though it's theoretically possible to embed all business logic inside
your logicsheet rules (a la MS's ASP) such approach is flawed: it
reusability, complicates debugging and may easily result in invalid
code being generated (e.g. variable name clashes)

In Cocoon1, taglibs were implemented as XSLT stylesheets. While valid
(after all, dynamic tag substitution is just another case of XML
tranformation) this may easily become overwhelmingly complex: XSLT's
syntax is too low level for the sort of transformation required for
source code generation. Think of what's involved in supporting
interchangeable attribute/element parameter passing, quoted string
generation or the need to copy-over all unrecognized tags.

SiLLy provides a much higher-level syntax that allows the logicsheet
author (yes, a programmer) to focus on the _mapping_ between tag names
and method invocation.

Briefly stated: logicsheets are meant for tag-to-code _mapping_,
not for free-form code inlining.

View raw message