cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: XSP Changes and Fixes
Date Wed, 21 Jun 2000 21:47:25 GMT
Ricardo Rocha wrote:
> 
> 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.
> 

Hey, guy, that's great news !!

Could this mean that if we write a generic filter handler and a
last-step logicsheet we can easyly address this to compile the sitemap ?

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message