You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xsp-dev@xml.apache.org by Matt Sergeant <ma...@sergeant.org> on 2001/03/05 11:16:18 UTC

Re-using XSP internally in Cocoon (was Re: [RT] Rationalizing XSP (was: XSP and aspects))

On Fri, 2 Mar 2001, Ricardo Rocha wrote:

> 3) Refactoring the XSP implementation to avoid redundance
> 
> Currently, there are 2 overlapping, redundant "markup languages" in
> Cocoon2: XSP for server pages and XSP for the sitemap. Allan Erskine
> also mentions a possible "flowmap" which (in the current setup) would
> require the creation of a third MarkupLanguage implementation.
> 
> Historically, the MarkupLanguage abstraction was meant to signify
> different code generation tagsets, namely: XSP (<xsp:logic>, <xsp:expr>)
> and JSP (<jsp:scriptlet>, <jsp:expr>). Admittedly, even for this case it
> was unnecessary: it would be much simpler to translate JSP code
> generation tags into their XSP counterparts without the need to
> introduce the notion of a code-generation markup language (SOM!)
> 
> When the need for sitemap compilation was perceived and its
> implementation pursued, "MarkupLanguage" was understood as what I've
> called above the "program unit skeleton" so a new MarkupLanguage
> (pirated from the server pages XSP implementation) was created:
> SitemapMarkupLanguage.
> 
> In fact, this was the only possible workaround that allowed the existing
> XSP code generation framework to be reused.
> 
> Should I have timely decoupled the code generation engine from the
> target program type, we wouldn't have a separate sitemap MarkupLanguage
> today. Again:SOM! :-(
> 
> Fortunately, the solution is obvious: deprecating MarkupLanguage and
> adding a separate program skeleton logicsheet step in the XSP code
> generation pipeline.
> 
> This way, both the sitemap and server pages can reuse the code
> generation machinery without redundance.
> 
> This is also true for "new" program types such as Transformers and, yes,
> Allan's flowmap.

This is a cocoon issue and should probably not have been included in this
RT to xsp-dev.

-- 
<Matt/>

    /||    ** Founder and CTO  **  **   http://axkit.com/     **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** mod_perl news and resources: http://take23.org  **
     \\//
     //\\
    //  \\