cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon2 Design
Date Tue, 30 May 2000 22:18:40 GMT
Neeme Praks wrote:
> 
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > 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. 

You're right.

> They could be java classes that can alter the workflow of cocoon. 

Hmmm...

> For example, I can call URL
> /screen/mypage/action/myaction. This would tell Turbine the usual stuff:
> execute action myaction.java and then execute screen "mypage". The
> screen could be implemented as XSP page. The action myaction.java would
> be able to alter the screen (XSP page) to be displayed/executed... well,
> this starts to look more and more like Turbine... ;-)

I don't like this. You are placing logic into the URI, thus overlapping
the administrator and logic contexts and creating unnecessary (and
time-expensive) contracts.

Turbine Actions look a lot like Cocoon2 matchers to me.
 
> > > 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 ;-(

He's not only excited, he's blinded by it. But he never did content
syndacation in its web applications so he doesn't know that complexity
this adds to the picture. (as much as I don't know many of the issues
for web application development, and you can clearly tell from Cocoon1)

> I think about trying to implement this myself at some point of time, to
> get better understanding of both (Cocoon and Turbine).

This will be valuable feedback for all of us.

> Actually, my final aim is to use Jetspeed with Cocoon (as a component),
> I'll get back to this topic in some other post.

Cool.
 
> > I don't think using Turbine as a Cocoon component would work...
> 
> why not? Any specific reason?

No, just a feeling.
 
> > > 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
> work...

It won't do rewriting but internal redirections. Anyway, it's too early
to tell, we are still designing those pieces.
 
> > 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...

Right. And I believe Turbine Actions can be separated into Cocoon2
sitemap + matchers.
 
> > 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.

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

Yep.

Well, ECS could be updated to return SAX events.... but then you must
make Turbine aware of SAX and make it a generator.... so if you do, it
becomes an XTurbine :)
 
> > 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...

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

I believe the latest Cocoon2 sitemap WD I recently proposed clones
everything that Turbine has, while adding much more flexibility in the
separation of concerns side of things.

But this is, as always, my personal opinion. We need to test it on the
field to find out.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message