cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject XSP Changes and Fixes
Date Wed, 21 Jun 2000 21:05:07 GMT
As you know, the XSP implementation has been completely
revamped for Cocoon2.

Beyond fixing many problems found in its previous incarnation,
this implementation is based on a much cleaner, abstract and
extensible design that is also better integrated with Cocoon's

This new design eliminates a number of problems present in XSP
for Cocoon1, most notably:

- Inadequate namespace handling
- Tight coupling with the servlet environment
- Excessive complexity in logicsheet authoring

Besides this externally visible shortcomings, the XSP implementation
for Cocoon1 is not easily maintainable or extensible: it's not based
on a well thought out set of abstractions.

XSP for Cocoon2 addresses all these concerns and provides an
extensible implementation that is:

- Independent of the Cocoon execution environment: servlet, offline,
- More reusable: markup-to-code generation can be used outside the
  Cocoon environment.
- Programming-language-independent: supports Java, other languages
  compiled to class files and interpreted languages.
- Markup-language-independent: Supports any markup language, in
  addition to XSP.

XSP page and logicsheet authoring have been greatly simplified, too.

Thus, for example, the need for a root <xsp:page> element or for
special processing instructions is being removed.

A logicsheet language (sll or "SiLLy") is also being developed that
simplifies logicsheet authoring dramatically.

(See inlined example below)

Last, but not least, the XSP code-generation engine may used to
generate different types of XML processors: generators, filters,

Currently, only generators are supported. This is _not_ wired
into the code generation engine, though! Implementing a filter
code generator, for instance, is simply a matter of writing the
appropriate pair: a generic filter handler and a last-step

What about XSP for Cocoon1?

While all this sounds like good news, the Cocoon1 XSP implementation
requires fixing the above-mentioned problems. This is also true of the
existing documentation, which (shame on me!) hasn't been updated in a

I've considered an intriguing idea: replacing the existing Cocoon1 XSP
implementation with Cocoon2's.

Anyway, I'm almost done with my current activities so all of the pending
issues should be dealt with soon.



An (improvised) Example:

<!-- No root <xsp:page> necessary -->

  <!-- "mail" logicsheet is not namespace-mapped, include it -->
  <sll:use-logicsheet href="logicsheets/mail.sll"/>

      <!-- Try and send message -->
          <request:get-parameter name="host" default="localhost"/>
          <request:get-parameter name="from"/>
          <request:get-parameter name="to" as="array"/>
          <request:get-parameter name="subject"/>

      <!-- All's well that ends well, declare victory -->
      <title>Message Sent</title>

        Your message has been sent. Please, click
          <link href="index.xsp">here</link>
        to continue.

      <util:when error="authentication"> <!-- Set by the mail logicsheet
          There has been a problem with your mail credentials:
          There has been an unexpected problem. Please consult with your
          system administrator.
        <title>Error Sending Message</title>


        <!-- Return to calling form (uses session) -->
          Please, click
	    <form:retry restore-parameters="true">
	  to try again.

Where "util.sll" contains a template like:

<sll:match-element name="try" prefix="util">
  <sll:argument name="body" required="true"/>
  <sll:argument name="on-error" required="true"/>
      try {
        <sll:argument-value name="body"/>
      } <xsl:apply-templates select="on-error"/>

Note that XSL directives can be freely interspersed in
sll: a SiLLy logicsheet is actually transformed into an
equivalent XSL stylsheet.

View raw message