cocoon-users 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: App Design Philosophy Rant
Date Mon, 19 Feb 2001 01:40:23 GMT

----- Original Message -----
From: "Paul Russell" <paul@luminas.co.uk>
To: <cocoon-users@xml.apache.org>
Sent: Wednesday, February 14, 2001 9:27 AM
Subject: Re: App Design Philosophy Rant


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

Thanks for the answer...it's interesting stuff.  What do you think would
happen, say, if an AxKit person decided they liked sitemaps, and implemented
sitemap functionality as a logicsheet?  (worse still, what if a C2 person
implemented a sitemap logicsheet, including a patch for sitemap.xmap that
read -.-.-....+<map:generate "sitemap.xsp"/> -.-.-.-.-.?)

Since sitemap activity happens pre-generation stage, this would presumably
stretch the <xsp:structure/> or pre-<user-root> <xsp:logic> cababilities.
There would need to be code run before any generating was done....but if
this led to a refining of XSP to allow for code to be run before generating,
surely everyone's a winner?

In a way a sitemap not only resembles an XSP page,  it's a dream XSP page!
(since there's never any nasty embedded code constructs)  I hope this is the
direction of XSP too (markup, not code)...and I think the sitemap logicsheet
would be an example for everyone to aspire to ;)

Also there are some technologies that sit uneasily between the sitemap and
XSP.  On Uli's advice I've been checking out the Schemox and Lexus pages
(http://www.infozone-group.org/projects_main.html)   They're quite rightly
fans of C2 and are working on integrating, but so far this seems to amount
to wrapping their code as a generator.....

I think Schemox and Lexus would be ideal canditates for logicsheets (very
useful logicsheets at that), since
logicsheets are the obvious forum for integrating external
technologies....(Schemox forms filled
with esql data + links for each row added through Lexus blah blah)...using
the current Schemox integration seems tricky, and looks like it would need
some recursive use of the sitemap for maximum flexibility

An XSP sitemap would already have addressed it's intimate relationship with
XSP (an other) generators.....the relationship would be recursive by
default, and presumably the XSPGenerator thread on cocoon-dev recently would
have been much shorter as a result...an XSP sitemap would also address basic
content aggregation by default.  (and caching/recompilation too - when was
the last time the sitemap recompiled properly without needing a restart?)
The C2 codebase would also presumably shrink...

To the extent that there are recurring problems integrating logicsheets,
they will presumably be rectified (by SiLLy, say).  But will the sitemap
benefit?  The same goes for XSP not benefiting from sitemap
developments...you might reach the stage where a sitemap.sll "hack" becomes
easier to maintain than sitemap.xsl/SitemapMarkupLanguage anyway...

So my question is, and I know it's late in the day, are you all sure, sure,
sure as can be, that maintaining the two technology bases (sitemap & XSP)
isn't spreading each too thin?  and has anyone written a sitemap logicsheet
I can borrow;) ?  Give me a yes (for either question), and I'll stop ranting
and do something useful....

- Allan

> > > 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
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail: <cocoon-users-help@xml.apache.org>
>



Mime
View raw message