Re: XSP and Aspects (was Re: [RT] Rationalizing XSP (was: XSP and aspects))

[Allan Erskine <a....@cs.ucl.ac.uk>]

> 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 don't think anyone was suggesting an explicit aspect construct.  Rather we
were just observing that well chosen markup can help capture aspects, these
being items/features that would otherwise crosscut our system.  Seeing as
we're all engaging in this anyway, I don't see the problem in adopting
"aspect" as our terminology, and using this terminology to shape our guiding
principles.

----- Original Message -----
From: "Matt Sergeant" <ma...@sergeant.org>
To: "Ricardo Rocha" <ri...@apache.org>
Cc: "XSPDev" <xs...@xml.apache.org>
Sent: Monday, March 05, 2001 9:58 AM
Subject: XSP and Aspects (was Re: [RT] Rationalizing XSP (was: XSP and
aspects))


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