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: [C2] XSP and apects (was: log performance penalties)
Date Tue, 27 Feb 2001 02:58:42 GMT
Thanks for the reply.  I a bit feel misrepresented on some parts - my
fault though...(original message was one of these 5am moments
of "clarity")...I've tried to redress this below; hopefully my suggestions
won't appear quite as 'out there' this time...apologies to those that regard
some of this OT....

----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>
To: "cocoon-dev" <cocoon-dev@xml.apache.org>
Sent: Friday, February 23, 2001 12:59 PM
Subject: Re: [C2] XSP and apects (was: log performance penalties)


> ----- 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.

This had occurred to me.  Since XSP and
logicsheets were designed with SoC in mind, might I have confused aspects
with concerns and pointed out the startlingly obvious?

Well, hopefully not!  Here's where I was coming from...

Assuming a "concern" in this context is taken as delimiting a
broad area of interest, such as presentation or application logic, I
believe that my use of the word aspect is actually closer to what it usually
means in AOP, namely a feature that crosscuts many system components.

The difference between implementing aspects in a general purpose programming
language (like Java) and implementing aspects in a restricted purpose, but
extensible language (like XSP) lies in the manner in which aspects are
modularised/captured.

In aspectJ, the aspect construct is provided as a modularisation unit for
crosscutting concerns.

In XSP, what appears to happen is that markup is chosen to
represents and encapsulate what would otherwise be a crosscutting feature,
that is to say,
markup-constructs are being deliberately chosen to capture aspects.
(regardless of whether the
crosscutting feature/aspect represents a complete concern area).

And so my proposition is just the simple observation that as well as being
pivotal in separating the concerns in cocoon's "pyramid of contracts" model,
XSP markup is flexible enough to capture aspects that would crosscut the
system if hardcoded.  This is why I'm a *fan* of XSP, and would seek to
expand and refine it's role.

I hope this sounds reasonable...

> >  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.

I agree; server-side presentation processing is my sole concern here.

> >  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"

Sure...thanks for trying to set me straight.  While being fully aware of the
dangers of FS, I also think you have to recognise the futility of not
following ideas through to full utility.  And XSP + logicsheets strike me as
a very worthy combo for further development.

> > 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.

See opening statements...I'm not trying to use XML to add aspects to
anything - I'm merely noting the facility of XSP + logicsheets to delineate
aspects within an XML server system...what I'm wondering is, can this power
can be successfully and appropriately utilised elsewhere (ie other than just
page generation)?

> >  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.

OK - that was the 5am clarity statement.  Forgive my hyperbole, but please
don't dismiss me out of hand.  I was thinking here of XSP's potential as a
general purpose factory for server components other than XSPGenerators...it
would be a
natural for this as it has already started to prove itself as an integration
technology;  it would make my life simpler for one to have that flexibility
in component construction available from sitemap calls other than
map:generate.

Decreasing learning costs and improving maintenance is my middle name!  And
also _would_ be a potential benefit of expanding XSP's remit.  Decreased
learning cost - you just have
to learn XSP.  Decreased maintanence - XSP markup has demonstrated it's
utility in separating concerns, and capturing aspects.

> 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!

Again I agree:  *WRONG!*.  So here's where you'd start to think of improving
XSP instead, precisely to address your concerns.  And if we agree that the
language independance of XSP pages has to an extent encapsulated the "choice
of implementation language" aspect, then _any_ language specific programming
constructs in XSP are WRONG, since they break this encapsulation!

Following this line of reasoning, the first thing you'd add to XSP would be
the option to insist on only pure markup in an XSP page, no recourse to the
underlying programming language.  This is definitely a direction I'd like to
see for XSP, since it would encourage good style and portability, as well as
the development of more powerful, flexible, and self-contained logicsheets.
An XSP sitemap would be a sterling example to future logicsheet authors,
precisely because programmability would be disabled, and the logicsheet
represent all possible configurations of a self-contained  and powerful XML
server component.

An additional restriction to consider would be to allow a logicsheet to
declare itself uncompatible with anything but "friend" logicsheets, or at
least to declare that they can only be used in certain restricted contexts.
This
could ensure markup mixing only occured up to the point anticipated by the
logicsheet authors (if this were appropriate).  For example a sitemap
logicsheet could declare that the flowmap logicsheet was the only other
permissable markup in such hypothetical XSP components.  This again would
help enforce separation.

> 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.

Again I say make it a feature of XSP to allow disabling of programming
constructs, and even allow disabling other logicsheets (ie, allow to specify
that a logicsheet can only be used standalone).  This I believe would
benefit XSP;  in general I believe expanding the remit of XSP would lead to
a synergy between the development of XSP with the development of integrated
XML
technology solutions within it.  With appropriate refinements in place, I
don't see the obstacle to having an XSP sitemap, rather I see the benefit.

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

I know this.  Experience can also be distilled into combinations of markup
constructs.  This is the driving force for the creation of XSP
logicsheets...but so long as XSP is restricted to pages, and not more
general XML server processes, I'm not convinced how strong this driving
force will be.

Besides, some logicsheet tags already sit very uncomfortably between
xsp:page tags, IMO, and this alone should be enough to start forcing a new
development in the language.  A large proportion of the ldap, esql, and
sendmail tags should really belong in a new XSP construct for marking up XML
server processes.  What does sending an email or updating a database have to
do with generating a page?  And as for the SOAP taglib....

I think this alone is worth some attention...

> >, 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?

I'm terribly sorry!  Proprietary could hardly be a worse word to use for one
of the most open of open source projects.  But still, saying "cocoon has
an XSP language for integrating technologies with markup constructs, but
only within "pages", whatever they are, and it also has a sitemap" sounds
more proprietary to me than "cocoon is a platform for integrating
XML server technologies using XSP, an extensible XML server processing
language"

I used the term rationalised because at the moment the sitemap and XSP pages
need to be pre-compiled, cached, re-compiled, aggregated, etc in two similar
but different ways.  If another technology, eg a flowmap were to be added
that operated in a third "the same but different" way, would this not be an
indicator that a unification should be sought?  Such a unification would
presumably rationalise parts of the codebase.

XSP's current an future structure is (and should be) an open invitation to
extension, integration, and continued development.  I need convinced
the same can be said as easily of the sitemap.

> > (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.

When Uli used the term rant, it was only in humility I'm sure.  The thread
he started should have been entitiled "a timely expose and invitation
to discussion of cocoon in web-apps".  Several other threads on
cocoon-users have gone this way recently too...

> 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.

I hope I'm not being dim-witted, but I still don't quite understand what
these costs might be...  Unification of concept isn't a cost.  The sitemap
could probably
already be hacked into an XSP page (using inner classes perhaps?) as it
stands (not that I'd recommend this).  Some simple refinements to XSP could
make for the simple, powerful and flexible configuration of a myriad cocoon
components, as well as broadening XSP's scope.  I'm afraid I am still in
need of further enlightenment as to why this is not appropriate...

> 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.

Just to reiterate, I don't recommend this.  I do wonder though of the
potential in new XSP constructs (some being explicitly unprogrammable
except through logicsheet markup), and consequently of XSP's suitability
across the board as the language of XML servers.

> > (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.

Just to reiterate, this was not what I was proposing.

> what we need is more thinking not rants.

I'm thinking - I'm thinking!!  I'm also an experienced developer with some
time on my hands (became a student again..ahhhh relief!)...I'd like to be
able to find common ground here, and hopefully muck in...

- Allan

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




Mime
View raw message