xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <m...@sergeant.org>
Subject Re: Deprecating the <xsp:page> root element
Date Wed, 08 Nov 2000 16:46:33 GMT
On Wed, 8 Nov 2000, Ricardo Rocha wrote:

> The "encoding" attribute introduced in Cocoon2, should remain in
> place as a root-level attribute:
> 
>   <page xsp:encoding="Cp1251" ...>
> 
> This attribute is clearly redundant with respect to the
> standard directive:
> 
>   <?xml version="1.0" encoding="Cp1251"?>
> 
> Unfortunately, however, the SAX (and DOM) API's doesn't provide
> a standard way of quering the parser for the  original document
> encoding.
> 
> For the Java language (at least) this information is necessary
> to direct the compiler to generate a class with the proper
> string encoding (javac -encoding ...)

Hmm, why don't you get everything from the parser in UTF16 (or UTF8)? I'm
confused...

> It's somewhat untasteful to include a directive like this in the XSP
> language because a particular language requires it.
> 
> Probably (along the lines of the [Cocoon] environment-specific
> directives suggested above) a language-specific tagset and
> namespace should be defined that account for this sort of
> need:
> 
>   <page java:encoding="..." ...>
> 
> As we'll see in upcoming posts (when discussing decoupling XSP
> from target source program types) it is possible to use XSP's
> code generation machinery for environments other than Cocoon
> and web applications.
> 
> For this genericity, it's conceivable that a target XML API
> can also be defined (SAX, DOM, JDOM) so that the appropriate
> code is emitted and the appropriate logicsheets are selected
> for code generation.
> 
> In this scenario, the following factors would govern code
> generation:
> 
> - Markup language (XSP, JSP)
> - Programming language (Java, Perl, ...)
> - Environemnt (e.g. servlet, offline, ...)
> - Target API (SAX, DOM, JDOM)
> - Target source program type (Generator, Transformer, ...)

I smell complexity rearing its ugly head... I'd certainly rather focus on
a spec for the tags themselves, than worrying about code generation for
different languages - let the implementor take care of that, at least
until we have compatible implementations :-)

> Back to our main subject...
> 
> Another use of the <xsp:page> element is to provide the top-level
> context in which to import external modules and to declare class-level
> logic:
> 
>   <xsp:page ...>
>     <xsp:structure>
>       <xsp:include>java.text.SimpleDateFormat</xsp:include>
>     </xsp:structure>
>     <xsp:logic>
>       private static String systemTime(String formatMask) {
>         return new SimpleDateFormat(formatMask).format(new Date());
>       }
>     </xsp:logic>
>     <page> ... </page>
>   </xsp:page>
> 
> In absence of a <xsp:page> root element, the same effect can be
> achieved by stating that <xsp:structure> can only occur as a
> top-level element, immediately below the [user] root element and
> that any <xsp:logic> elements inside <xsp:structure> are to be
> treated as class-level logic:
> 
>   <page xmlns:xsp="http://apache.org/xsp">
>     <xsp:structure>
>       <xsp:import>java.text.SimpleDateFormat</xsp:import>
>       <xsp:logic>
>         static String systemDate(String formatMask) {
>           return new SimpleDateFormat(formatMask).format(new Date());
>         }
>       </xsp:logic>
>     <xsp:structure>
>     . . .
>   </page>
> 
> Note that, in the above snippet, we have replaced <xsp:include> by
> <xsp:import>.
> 
> This is another proposed change: deprecate <xsp:include> in favor
> of <xsp:import>
> 
> The term "include" is usually associated with [generation-time]
> inclusion semantics (think of JSP's <%include%> directive). This is
> clearly not the case here. The term "import", on the other hand, is
> used consistently with module import semantics in other languages
> besides Java.
> 
> In regard to generation-time document inclusion, it is our opinion
> that logicsheets (and external entities) make it unnecessary and
> redundant.
> 
> Logicsheets can easily and uniformly account for the type of
> need addressed by generation-time inclusion directives (such as
> JSP's <%include%>).
> 
> Generation-time inclusion by means of external entities is highly
> discuraged since it doesn't allow for the dependency checking required
> to regenerate compiled programs when their source files (logichseets,
> included documents) change on disk.

That quite frankly is a Cocoon bug. Everything else I agree with.

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\


Mime
View raw message