cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Erskine" <a.ersk...@cs.ucl.ac.uk>
Subject Re: [RT] Flowmaps, propagation, and aspect-oriented data processing
Date Mon, 19 Mar 2001 19:26:13 GMT
C2's sitemap and flowmap should hopefully be an excellent subject for your
talk.  I've added some comments below...

----- Original Message -----
From: "Robin Green" <greenrd@hotmail.com>

...

>
> Some might argue that <map:match> "doesn't count" or "is trivial" as an
> aspect-oriented tool, because it "only" crosscuts data, not code.
> Admittedly, the sitemap code probably is much simpler than the AspectJ
> weaver, because its task is only to match requests with pipelines - not to
> read and modify existing classes. However, I intend to argue in my
> presentation that data-centric, as opposed to code-centric, separation of
> concerns is a worthwhile research area (which has significant overlaps
with
> its code-centric cousin) - especially given the substantial productivity
> gains systems like Cocoon can bring.

You've come up with some very interesting examples here - they seem to cover
the C2/XSP versions of static aspects, and aspect instances.

Roughly speaking, a static aspect can be advised to introduce new constructs
within static scope (so this can loosely be thought of as at 'code-level'),
whereas an aspect instance can have advice to introduce new code associated
with individual object instances, ie in dynamic scope (the example in the
AspectJ primer is of a set of 'shadow' coordinates, which are dynamically
associated with Point instances.)

So the sitemap's <match...> and pipeline constructs would be analogous to
aspect instances.  Matching and then performing transformation on a
generator in a pipleine is like saying:

aspect of:  all output from generator G (on some source)
advice:  when requested in URI space U (or more generally, when matched by
matcher M)
introduction:  introduce transformation and serialization pipeline mechanism
on the output.

In Ricardo's earlier thread [RT] Rationalising XSP, he proposes an extension
to the XSP code generation process to decouple XSP from only server pages
(making available for use with sitemap/flowmap logicsheets for example).
The first stage in the process he proposes is to apply aspect
logicsheets...this step would be analogous to static aspects IMO, the
similarity being that both involve adding constructs at the code-level.

So I'd propose that C2's equivelent of a static aspect would be an advice
dependent introduction of XSP constructs to the _input_ of some XSP
component generator.  At the moment, nothing like this has been implemented.

Correspondingly, C2's equivalent of an aspect instance (dynamic aspect)
would be an advice dependent introduction of some change/transformation to
the _output_ of some XSP component generator.

> ----------------
> 2. One advantage of flowmaps (see foot of email for a copy of Stefano's
> definition of flowmaps) that hasn't yet been mentioned is autopropagation
to
> further reduce redundancy - although perhaps this is only useful for a few
> concerns, like authorisation.

...

> 3.1. Hierarchical (or even non-hierarchical) menu systems. You might want
a
> sidebar always displaying a context-sensitive menubar, for example, but
it's
> a bad idea to redundantly place a submenu in every file in a directory,
> obviously. You can use some form of including, but one file per menu means
> menu files scattered all over, and one big menu file is better, but if you
> already have a graphical flowmap editor it makes sense to use this to edit
> menus rather than reinventing the wheel. (Hmmm, weak justification!)
>
> 3.2. Drag and drop a subnet to a new part of the flowmap, and it
> automatically picks up the "look-and-feel" of its new parent by
propagation,
> even if the subnet is implemented by a diverse set of pipelines! Of
course,
> this is just a sketchy idea without an implementation, and embodies
several
> big assumptions - that "branding" can be done with a cleanly separated
> stylesheet and/or transformer added on to the pipeline, for example. In
some
> simple cases it could be, but not in others. You also need a different
> definition of propagation because "look-and-feels" are not boolean
> functions, unlike constraints!
>
> Insert your ideas here please!

I like this idea...what we'd like to be able to do here is implement the
following dynamic aspect:

aspect of:  all server page generator output
advice:  when page generated from a URI contained in the URI space of the
flowmap
introduce:  an XML representation of the states navigable to from this point
in the flowmap (this XML could then be transformed into menu-bars or
whatever)

It strikes me that this aspect could be implemented with the new content
aggregation features which will hopefully be arriving soon (an aggregation
of an XML representation of the flowmap's current state and the page being
generated).

However, the sticking point is the implementation of the flowmap.  If XSP
were to be decoupled from just server pages generation, as per Ricardo's
proposal, we could leap in with a flowmap logicsheet to complement a new
sitemap logicsheet.

Until this happens though, adding a flowmap component will result in an
unacceptable code duplication and maintenance overhead.


> ----------
> 4. Principle of least surprise?
>
> One might object that autopropagation breaks the principle of least
> surprise, in that the look or behaviour of a resource in one part of a
> flowmap can be altered by a propagatable property of a distant resource,
> simply through reachability.
>
> But, even if this turns out to be significant, it is another example of
the
> trade-off involved in many kinds of separation of concerns - OOP has
fragile
> base classes, XSP potentially has logicsheet interference, and AspectJ has
> the very obvious drawback that, in a standard text editor or code listing
> printout, there is often no indication in a classes' source of if and
where
> an advice is being woven in (this is termed "reverse inheritance").
However,
> OOP and post-OOP techniques have been found that try to reduce the problem
> of fragile base classes; logicsheets can be written to avoid generated
> identifier clashes; and AspectJ has special IDE support. A graphical
flowmap
> editing tool could perhaps restore the principle of least surprise in this
> case too - and it would also have the advantage that a graphical diagram
is
> a much clearer representation of a flowmap than a textual XML tree, which
> must necessarily use labels to make links rather than pointing to them
> graphically.

I agree this is a problem.  C2 could probably do with better IDE
support...perhaps an emacs mode in the first instance.  One think that could
be done would be to map all C2 resources into a URI space (including XSP
files).  Then C2's mechanisms based on the sitemap, flowmap, or whatever
explicit aspect oriented constructs could be used to give hints to the idea
as to which XSP code is involved in what.

> -------
> Appendix: What is a flowmap? (with quibbles)
>
> >Stefano <stefano@apache.org> wrote:
> > > The solution I envision is the creation of a "flowmap" where the
web-app
> > > designer is not focused on intermediate locations (resources), but in
> > > the flow of the application, much like you procedural languages let
you
> > > program by writing a flow, not filling memory slots declaratively with
> > > instructions.
>
> I think this description is slightly misleading, because in the only
example
> given (Slashdot) states were effectively mapped 1-1 to resources (or, to
be
> precise, matching requests) - so the designer is focused on resources. And
> why not?
>
> However, multiple states could be handled by a single resource, so I sort
of
> see Stefano's point.
>
> > > So, what is a flowmap?
> > >
> > > Take a piece of paper, avoid thinking you are writing an application
for
> > > the web, so avoid taking into consideration technical constraints
(like
> > > the request/response paradigm, intrinsic statelessness, low bandwidth,
> > > proxying, etc..) and draw a diagram of the latest application you
wrote.
>
> [Whilst this might be a nice theory, I personally find it hard to think
> about an actual webapp without thinking in terms of responses and
requests!
> :) But that's just a quibble.]
>
> > >
> > > What you should outline, at this stage, is the 'skeleton' of the flow:
> > > this should be drawn to give the other people in the team the overlall
> > > picture of what the application is doing.
> > >
> > > So, let's see, let's take something like slashdot.org:
> > >
> > >
> > >          identification
> > >                ^
> > >                |
> > >                v
> > >  (enter) ---> home ---> (exit)
> > >                ^
> > >                |
> > >                +--> read article <-()-> post comment
> > >                |
> > >                +-()-> set preferences
> > >                |
> > >                +-()-> add article
> > >                |
> > >                +-(editor)-> accept submission
> > >
> > > where:
> > >
> > >  (enter) indicates the entrance of the application
> > >  (exit) guess what? :)
> > >  ---> indicates a 'general flow' [no restriction on identity]
> > >  <---> indicates a 'bidirectional flow'
> > >  -(???)-> indicates a 'restricted flow'
> > >  -()-> indicates a 'identificated flow'
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message