cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neeme Praks" <>
Subject RE: Cocoon2 Design
Date Tue, 30 May 2000 16:18:49 GMT

> -----Original Message-----
> From: Stefano Mazzocchi []
> Sent: Monday, May 29, 2000 9:39 PM
> > The best thing I like about Turbine is the possibility to separate
> > "actions" from "screens". So, in my vision, I would like to use XSP
> > (with XSLT) for user interface generation ("screen" in Turbine) and
> > system for having actions in Cocoon. Maybe also in the form of XSP
> > pages?
> why not...

well, I was thinking a little bit more about this. As screens are
actually outputting stuff and actions are not, then I don't see any need
for actions to be XSP pages. They could be java classes that can alter
the workflow of cocoon. For example, I can call URL
/screen/mypage/action/myaction. This would tell Turbine the usual stuff:
execute action and then execute screen "mypage". The
screen could be implemented as XSP page. The action would
be able to alter the screen (XSP page) to be displayed/executed... well,
this starts to look more and more like Turbine... ;-)

> > And how would Turbine fit in the Cocoon picture? As a generator?
> yes, that's a possibility, but I'm sure Jon would kill me if I ask him
> to make Turbine implement Generator and spit SAX events instead of raw
> bytes.

I suspect that Jon is too excited about webmacro right now to catch up
with this idea ;-(
I think about trying to implement this myself at some point of time, to
get better understanding of both (Cocoon and Turbine).
Actually, my final aim is to use Jetspeed with Cocoon (as a component),
I'll get back to this topic in some other post.

> I don't think using Turbine as a Cocoon component would work...

why not? Any specific reason?

> > The point being here that if I, for some personal reason, 
> don't like the
> > form of URL's that Turbine uses, then Cocoon would handle the URL
> > rewriting for me. 
> C'mon, use mod_rewrite for that, you don't need the Cocoon 
> architecture
> for plain URL rewriting.

Ok, maybe I got too carried away ;-)
I just read from some previous post that Cocoon2 sitemap could/should
handle also URL rewriting? So I was trying to imagine how this would

> Turbine, to me, seems like a big collection of java classes. Where is
> style-content separation? where is logic-content separation? where are
> the management contracts? embedded with code?

one part of the logic is in the "action" modules... Everything else I
would like to put in taglibs...

> I asked Jon if his new Scarab bug tracking system was capable of
> creating XML views of the pages so that we could use it as a generator
> and post-process the output and perform clear separations. But he told
> me I had to rewrite the "screens" for that.

probably you would have to change the way that the "screen-handling" is
done... So it outputs SAX events instead of ECS.

> Now, what is a turbine screen? A java class that has a 
> simil-DOM inside (ECS).
> Now, do I look like someone that is going to write "by hand" 
> XML content using DOM calls? are you nuts?

Well, it is not that "bad" ;-) You could have your screen just return a
string in an ECS StringElement object (I believe this is the way the
webmacro stuff is made, but I could be wrong). But still, it is a
_string_ that cannot be easily postprocessed by Cocoon... And this is
the thing I dislike the most.

> True, XSP with built-in logic are ugly and taglibs are not as powerful
> as pure java code, but writing content as DOM calls by hand? no way!
> I think Cocoon should not focus on the complexity associated with the
> _logic_ of web applictations. This is a real for programmers, this is
> where Turbine shines.

well, most of the logic can also be called from XSP logicsheet, so I
don't see very big problem here...

> The problem is that both Turbine and Cocoon overlap significantly with
> the advent of the sitemap and no simple aggregation (1 calls 2 or 2
> calls 1) is possible.

Actually I have started to get some vision, how Turbine would fit in
Cocoon. As I already mentioned, actions are for "pure" logic and can be
implemented as java classes. And I would prefer to use XSP as "screens".
The use of Xincludes should remove the need to use "navigations" and
"layouts" for display. And the use of Cocoon sitemap authorization
features should also remove the need to use "layouts" for authorization.

So, the only things left would be "actions" and "screens". Actions would
be java classes and screens would be XSP pages...
Still have to spend some more time on this, though...


View raw message