cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <p...@luminas.co.uk>
Subject Re: App Design Philosophy Rant
Date Wed, 14 Feb 2001 09:27:02 GMT
* Allan Erskine (a.erskine@cs.ucl.ac.uk) wrote :
> I was thinking that...haven't searched the archives on this, but sitemap
> markup is almost (not quite) a C2 logicsheet/taglib for orchestrating
> request processing.  At some point in C2 history it must have been a close
> call;  although speaking as a novice, surely a lot of the current
> aggregation discussion could have been avoided if the decision had been made
> to build a sitemap logicsheet/taglib, and forward requests to the
> root/default XSP page (which would either act like a sitemap, a normal page,
> or maybe a mixture of both).

Kinda. The sitemap is rather more involved than a simple XSP page. it
uses the same technology to generate source code representing the
sitemap.

> In other words, the sitemap is an aggregation mechanism....why wasn't it
> implemented in XSP, giving XSP all it's aggregation capabilities?  Someone
> out there must know the reason why...(and probably make me look daft for
> asking)

Basically because the sitemap has some very complex issues to deal with
(including in the future some fairly horrific caching algorithms etc).
Managing the logicsheet for building the sitemap is complex enough
already. Running the thing through the XSP logicsheet first seems like
overkill. Also, the generated sitemap extends AbstractSitemap, which
provides a lot of utility code which would otherwise need to be
generated time and time again.

> > What about seperation of content and logic, data driving processes and
> > all the other ideas that brought me to the Cocoon platform in the first
> > place? I don't need more features, I need more elegance :)

Interestingly, I find C2 much more 'elegent' than Cocoon1. It allows me
to achieve amazing results very simply, and lets me keep site management
outside the source files, which is what I'm after. I guess if you wanted
to, you could still use processing instructions to steer the generation
(maybe inside a CocoonOneGenerator ;)

> Of course, it's too easy to complain about this without providing a
> solution...Stephano has promised a posting soon on cocoon-dev to try and
> clarify C2's web-app direction...must admit I'm looking forward to it!

C2 is getting much closer to being good for webapps. It already
outstrips C1 by a large margin. For example, Actions provide a much more
powerful way of dealing with data manipulation and updates, should allow
us to have components which update EJBs, databases etc automatically.
XSP allows us to drag information from EJBs live without writing any
EJB specific code (by using castor). Skinning a website is stupidly easy
(see the RegexpTargetHostMatcher). We should have one of the fastest
ways of developing web apps on the planet, particularly as GUI tools
become available to help people build the applications.


Paul.

-- 
Paul Russell                                 Email:   paul@luminas.co.uk
Technical Director                             Tel:  +44 (0)20 8553 6622
Luminas Internet Applications                  Fax:  +44 (0)870 28 47489
This is not an official statement or order.    Web:    www.luminas.co.uk

Mime
View raw message