cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From " Stefano Mazzocchi" <stef...@apache.org>
Subject Re: [C2] XSP and apects (was: log performance penalties)
Date Fri, 23 Feb 2001 12:59:39 GMT
----- Original Message -----
From: "Allan Erskine" <a.erskine@cs.ucl.ac.uk>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, February 23, 2001 5:05 AM
Subject: [C2] XSP and apects (was: log performance penalties)


> ----- Original Message -----
> From: "Stefano Mazzocchi" <stefano@apache.org>
>
> > Of course, the real solution would be to use AspectJ to code Cocoon, but
> > I'd rather wait until AspectJ stabilizes before moving to aspect
> > oriented programming. [for those of you who don't know what I'm talking
> > about, look at www.aspectj.org for more info on ASP for Java]
> >
>
> XSP seems nothing short of an aspect abstraction mechanism.

Well, thanks for saying this. Interesting enough, this is exactly what
Ricardo and I were discussing a months ago privately, the only problem is
the XML syntax which is very unfriendly with code.

So, while I agree with your vision, I'd suggest to be careful: XSP was
designed with SoC in mind as well as ASP. So it's very likely that you
percieve both as the same, but it's logically wrong since XSP (at least 1.0,
the current) is targetted to server page generation, not to code generation
in general.

>  Aspects of
> server processing can be abstracted by tags, and modularised by namespace
> prefixing.

Yes, but I believe that it would be *much* better to avoid using the XML
syntax for that if all you want is code generation.

>  Even language and platform choice are aspects unders XSP's remit
> (witness AxKit).  Surely too useful for just pages (which are becoming an
> outmoded concept anyway).  Besides, being eXtensible conflicts with being
> restricted to page serving...

Well, eXtensible doesn't mean "must do everything and brew coffee"

> IMHO, XSP's scope should be broadened to include server processes
(sitemaps,
> actions, ...), and XML fragment generation.

As for XML fragment generation, this will be already in place once 'content
aggregation' is implemented.

As for sitemaps and actions, I completely disagree: if you mean that java
falls short since it's not really aspect oriented, well, I totally agree
with you, but if you believe that using the XML syntax to add aspects to
java, well, I believe this is big time FS.

>  I truly believe this would be
> powerful beyond belief (esp with recursive sitemap calling, and
sub-pipeline
> includes)

recursive sitemap calling? are you kidding? Please, this is *exactly* the
reasoning path that leads to flexibility syndrome: if 'a' and 'b' are great,
extending to 'z' will make it better. This is, generally, wrong since it
doesn't take into consideration the 'costs' of such an approach. Cost in
both learning, using and, even more important, maintaining.

And, last but not least, understanding the impact over SoC and the cost
metrics of a web publishing framework: making a sitemap programmable
directly is not only dangerous, is WRONG.

I repeat: WRONG!

because who administers the sitemap (the usability engineer, you might want
to call it) is almost never a programmer (programmers, by definition, have a
distorted view of usability anyway) and publishing systems have a very well
defined set of aspects, components and behaviors that must not be left to
everyone to rediscover or reinvent.

This is what a framework is: experience distilled into practices.

>, and it could be done without breaking the current XSP.  In a
> stroke, XSP's profile would be boosted, and C2 would be less proprietary
> (becoming a framework for XSP publishing components).  C2's codebase would
> also presumably shrink and be rationalised.

proprietary? rationalized? are we talking about the same Cocoon?

> (conclusion reached after following Uli's application rant on
cocoon-users,
> and developing my own C2 web-app, writing action after action to do the
same
> thing for different forms, longing for XSP actions, feeling locked in by
> proprietary sitemap.  Just the usual $0.02 worth in other words).

I don't follow cocoon-users and I believe that placing a rant on
cocoon-users is totally meaningless.

Cocoon was not designed with webapps in mind, admittely, not even Cocoon2 so
far and the 'action proposal' is not enough thought out to represent a clear
design (even Giacomo agrees with me on this).

Admittedly, this is a problem, but moving XSP to cover everything results in
costs many will not be able to afford.

Do you want a design that brings Cocoon's publishing elegance to include the
functionality required by web applications? I do. I feel this is the only
thing that might impact the Cocoon API and thus, the only thing that stops
us for entering 'beta' state.

How do we do that? are actions and HTTP action handlers enough? how reusable
can be make actions? how granular the MVC patterns can be applied to the
generation stage? how much overlap there is between existing solutions like
Turbine or Struts, how much can we reuse of their models?

Making the sitemap directly programmable is nothing different from writing a
big servlet that uses Cocoon components as it wishes. Result: 'subversion of
control'. Another big anti-pattern.

> (and thanks to Paul Russel for the interesting reply to similar email on
> cocoon users...hope for the same, to shut me up once and for all about
> xsp sitemaps, or otherwise:)

Cocoon was designed with the idea that POST actions were handled by
something else. This has never been stated, but after careful thinking I
believe there is a specific asymmetry in how the system was designed.
Result: in Cocoon, GET is natural, POST is ackward.

This is what generates friction and ranting.

But I reanalized the architecture and found no evidence of this asymmetry in
the design, it's just a consequence of lack of focus on web applications.
Cocoon maps the IoC model of servlets and, just like servlets, it's totally
agnostic on how you build your web application, unlike frameworks like
Turbine or Struts that create patterns internally at the generation stage.

Cocoon personalization is based on generators: just like pure servlet
programming is hard and expensive, pure generator programming by code is
hard and expensive. So, what do we do?

Following the JSP patterns, we created the Cocoon equivalent of JSP model 1
with XSP, but we stopped there:  XSP were not designed with model 2 in mind,
thus MVC is not implemented in its design, but it's left to the ability of
the XSP author.

There are a few questions that we need to answer:

 1) how do we implement MVC in generators? (extend/modify XSP or use things
like Velocity/WebMacro)
 2) are actions general enough to belong to the sitemap?
 3) sitemaps are declarative pattern matching based on request and there is
no notion of flow, which is left implicit inside the web application. Is
there a way to identify a "flowmap"? Is this information useful? can this
enforce the use of top/down design on web applications, working along with
the usability engineer?

making the sitemap more programmable is not an advancement, it's a hack.

what we need is more thinking not rants.

Stefano.


Mime
View raw message