cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <rica...@apache.org>
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
framework.

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,
  etc.
- 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,
etc.

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
logicsheet.

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
while.

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.

Regards,

Ricardo

===================================================================
An (improvised) Example:

<!-- No root <xsp:page> necessary -->
<page
  xmlns:mail="http://mysite/mail"
  xmlns:form="http://plenix.org/xsp/form"
  xmlns:util="http://xml.apache.org/xsp/util">

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

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

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

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

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

        <error-text>
          <util:get-error-message/>
        <error-text>

        <!-- Return to calling form (uses session) -->
        <p>
          Please, click
	    <form:retry restore-parameters="true">
	      <form:link-text>here</form:link-text>
	      <form:error-message>
	        <util:get-error-message/>
	      </form:error-message>
	    </form:retry>
	  to try again.
      </util:finally>
    </util:on-error>
  </util:try>
</page>


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"/>
  <sll:body>
    <xsp:logic>
      try {
        <sll:argument-value name="body"/>
      } <xsl:apply-templates select="on-error"/>
    </xsp:logic>
  <sll:body>
</sll:match-element>

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

Mime
View raw message