cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <rica...@apache.org>
Subject Comments on XSP 1.1 (long)
Date Tue, 31 Oct 2000 14:55:00 GMT
Hi guys,

Stefano wrote:

> 2) Ricardo will write a document explaining the ideas for XSP 1.1 and
> SiLLy, hopefully, this will happen in the new (and yet to be created!)
> XSP-dev mail list so that the AxKit people can help us on this

Before presenting a formal document for discussion in the list, I'd
like to present some of the ideas being considered for XSP 1.1.

The most important changes being proposed are:

  1) Supressing the root <xsp:page> element
  2) Decoupling the code generator from the target compilation unit
  3) Adding caching semantics to the XSP language
  4) Adding a logicsheet language (SiLLy, Simple Logicsheet Language)


*** Supressing the root <xsp:page> element ***

The document type of an XSP page should be that of the document
itself, not <xsp:page>:

  <?xml version="1.0"?>
  <!-- Only used namespaces need to be declared -->
  <page xmlns:util="http://xml.apache.org/util">
    <title>A Simple XSP Page</title>
    <p>
      Hi! I'm an XSP page and, to the best of my knowledge,
      it's now <util:system-time format="hh:mm:ss"/>.
    </p>
  </page>

Forcing a root <xsp:page> element results in unnecessary verbosity
of XSP's. In the "ideal" case where all logic has been placed in 
logicsheets (so no <xsp:xxx> tags appear inside the document) the
<xsp:page> tag becomes redundant, since there can be _only one_
"user" root element immediately below it:

  <!-- Old fashioned way: XSP namespace must be declared too -->
  <xsp:page xmlns:util="http://xml.apache.org/util"
            xmlns:xsp="http://xml.apache.org/xsp">
    <page>
      <title>A Simple XSP Page</title>
      <p>
        Hi! I'm an XSP page and, to the best of my knowledge,
        it's now <util:system-time format="hh:mm:ss"/>.
      </p>
    </page>
  </xsp:page>

Currently, the only justification for a root <xsp:page> element is
the need to import classes as well as to declare class-level logic:

  <xsp:page xmlns:xsp="http://xml.apache.org/xsp">
    <xsp:structure>
      <xsp:include>java.text.*</xsp:include>
    </xsp:structure>
    <xsp:logic>
      private static int cnt = 0;
      static synchronized int getCount() {return ++cnt; }
    </xsp:logic>
    <page>
      <title>A Simple XSP Page</title>
      <p>
        Hi! I'm an XSP page and I've been hit
        <xsp:expr>getCount()</xsp:expr> times so far
      </p>
    </page>
  </xsp:page>


To account for this need, we may define a _top-level_ <xsp:structure>
element inside which only <xsp:import> and <xsp:logic> are valid.

    <page>
      <xsp:structure>
        <xsp:import>java.text.*</xsp:import>
        <xsp:logic>
          private static int cnt = 0;
          static synchronized int getCount() {return ++cnt; }
        </xsp:logic>
      </xsp:structure>

      <title>A Simple XSP Page</title>
      <p>
        Hi! I'm an XSP page and I've been hit
        <xsp:expr>getCount()</xsp:expr> times so far
      </p>
    </page>

NOTE: Here we're replacing <xsp:include> by <xsp:import>.
      This should avoid confusion with [compile-time] uri-inclusion
      semantics which, btw, XSP doesn't appear to need :-)

In addition to the above, some attributes in the <xsp:page> element
are currently used to specify the language and encoding (as well as
to force servlet session creation, but this is an ugly hack). These
directives could be rephrased as root-level attributes in the XSP
namespace:

  <page xsp:language="javascript"
        xmlns:xsp="http://xml.apache.org/xsp">
    . . .
  </page>


*** Decoupling the code generator from the target compilation unit ***

Currently, the last, code-generation transformation step carries
out two conceptually separate tasks: 1) transforming markup to code
and 2) providing a compilation unit skeleton.

(We use the programming language-agnostic term "compilation unit"
to refer to a complete source program. In the Java case this is a
class source file)

These 2 steps can and should be decoupled, so that XSP's code
generation machinery can be reused for program types other than
generators (e.g. transformers or even "batch" processors with a
main method that can be used outside Cocoon)

In general, XSP-related transformations are applied in the
following order:

a) Dynamic tag subsitution (more on logicsheets below)
b) Programming language-specific string collection and encoding
c) Program unit skeleton population
d) XSP directive processing and markup-to-code transformation

During dynamic tag substitution dynamic tags are replaced by their
associated program logic (i.e. they're translated into equivalent
<xsp:expr> and <xsp:logic> directives)

During string encoding, text (as made available by the SAX
"characters" event) is collected and encoded in accordance to
the string constant syntax dictated by the target programming
language. This step may include space optimizations such as
identifying common substrings.

During program unit skeleton population a complete source
program is generated by embedding the XSP page markup (as
augmented/transformed so far) inside an executable unit such
as a method call (e.g. inside the "generate()" method of a
Cocoon Generator).

Finally, during markup-to-code transformation, XSP directives
(namely <xsp:expr> and <xsp:logic>) are expanded to inline code.
Also, all remaining content (i.e. markup not belonging to the
XSP namespace) is transformed into equivalent [SAX event] code
capable of rebuilding the original markup.


*** Adding caching semantics to the XSP language ***

Currently, checking for changes in dynamic content forces XSP
authors to write code (i.e. override the default "hasChanged()"
method) to implement this caching operation. This is so because
this check must be performed on a per-page basis so it cannot be
safely implemented in a general way by means of logicsheets.

*** Adding a logicsheet language (SiLLy, Simple Logicsheet Language) ***

Mime
View raw message