xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <m...@sergeant.org>
Subject XSP and Aspects (was Re: [RT] Rationalizing XSP (was: XSP and aspects))
Date Mon, 05 Mar 2001 09:58:37 GMT
Note: I'm keeping these replies off cocoon-dev. I see no reason to CC
there - you're not CC'ing axkit-devel too.

I'm going to try and reply to each one of these separately.

On Fri, 2 Mar 2001, Ricardo Rocha wrote:

> 1) Capturing aspects in XSP
> 
> In Allan's words, capturing aspects in XSP boils down to choosing markup
> to represent and encapsulate what would otherwise be a crosscutting
> feature.
> 
> To begin, XSP is generally seen as a (source) code-generation markup
> language.
> 
>   NB: Implementation-wise, though, it could be an _object composition_
>       language instead, with no need to resort to code generation
>       except, perhaps, for supercompilation-like optimizations. (I'd
>       like to elaborate on this later, on a separate post: a
>       composition-oriented approach to dynamic XML generation based on
>       Avalon patterns.)
> 
> AspectJ (our reference for AOP) acts as a Java preprocessor thus also
> "incurring" in code generation.
> 
> Aspects observe and react to object events such as method invocations or
>  exception handling. AspectJ achieves this by inserting aspect-support
> code at appropriate spots (join points) so that the crosscutting feature
> is accounted for in a transparent and uniform fashion across different
> classes.
> 
>   OT: With the introduction of dynamic proxies in Java 1.3,
> preprocessing
>       is no longer the only obvious option: it's now possible to trap
>       method invocations and exception throwing using dynamic proxies.
> 
> XSP code generation can be easily used for the same purpose although, as
> Stefano points out, XML syntax is very unfriendly with code (the
> "language impedance" issue commented below)
> 
> Consider XSP page debugging: the XSP code generator could well adorn
> generated code to keep track of source lines in the XSP page and all
> intervening logicsheets. Thus, when an exception is thrown, this
> information would be used to dynamically generate an error page
> displaying the appropriate context for the generated source program,
> the original XSP page and all relevant logicsheets: an XSP developer's
> nirvana! :-)
> 
> In fact, this wouldn't need to be the code generator's responsibility:
> an otherwise "regular" logicsheet could be applied that scans all
> <xsp:expr> and <xsp:logic> tags in order to append location info to the
> generated source program. All in an aspect-oriented fashion.
> 
> Of course, there are many more implications to making XSP aspect-aware,
> but one could say that the basic mechanisms needed to achieve are
> already in place.
> 
> If we refine the logicsheet applying mechanism and (ideally) also
> disallow embedding raw code in XSP pages (i.e., we base all dynamic XML
> generation on logicsheets) then capturing/representing aspects would
> become much simpler. (This is even more obvious under the composition
> model mentioned above.)

What I'm hearing is that aspects are something that someone invented
because of the weakness of Java's dynamism. In Perl inserting a proxy
object to catch method calls and such is pretty trivial, so we don't name 
it, that's just "programming perl" :-)

Having said that, I don't think you've really identified a problem with
XSP, so I'm not sure what this would gain us. It seems like somebody's
pontification turned into an RT, without any real purpose.

I'll come onto removing raw code in XSP in one of the other sections where
it's more relevant.

-- 
<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  **
     \\//
     //\\
    //  \\


Mime
View raw message