cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: App Design Philosophy Rant
Date Wed, 14 Feb 2001 10:45:47 GMT
Paul Russell wrote:
> * 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.

I can totally support this. From a project we've build on to of C2 
(an e-shop) I can add here that strictly separating content, logic and style 
will do the thing very fast and easy maintainable by different groups of 
people. If you build web-apps with C2 you have to further divide the logic 
part into logic to produce a view of a resource (XSP, pull) and logic that 
controls and manipulate your business objects (Actions, push). 

If you like to cover the publishing aspects only and you don't like to use C2 
as a web-app framework too there is no problem. Don't use the Actions. But 
don't put manipulation logic into your XSP pages than and probabbly don't use 
forms. IMHO you almost always end up in a mess because XSP pages are only 
made to produce views of a business aspect but not to manipulate it.

I admit that Actions are based on a lower level compared to 
Generators/Transformer etc. and they don't offer much reusability or 
generality. This fact is based on the difference between publishing systems 
and web-apps. A publishing system maps URL onto resource views whereas a 
web-app maps Events. But as Actions are very easy to write, almost every 
junior java programmer can do that. This is not the fact for XSP pages nor 
for logicsheets right now. Also using Actions leads to a better 
collaborative work on web-app and publishing projects where you can spread 
the tasks among people with different skills and experiance in your problem 
domain.

Giacomo

Mime
View raw message