You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Neeme Praks <ne...@one.lv> on 2000/05/29 19:50:45 UTC

RE: Cocoon2 Design

> -----Original Message-----
> From: Giacomo Pati [mailto:giacomo@simba.pwr.ch]
> Sent: Monday, May 29, 2000 6:59 AM
> 
> Many week ago I had the same thoughts. If you want to 
> integrate Cocoon 
> into Turbine you are at Jetspeed (Kevin has that already 
> done). If you 
> want to integrate Turbine into Cocoon (seems the better 
> aproache to me) 
> you have to rewrite some core functionality of Turbine to let'em spit 
> out XML. 

I also feel better about 
1. integrating Turbine into Cocoon
2. integrating Jetspeed also into Cocoon ;-)

Following all the sitemap development, it really starts to look
promising and I would love to use all the power of sitemap while
combining it with Turbine and Jetspeed.
I have some ideas, but I'm having hard time imagining how exactly
Turbine would fit in the Cocoon equation...

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?

And how would Turbine fit in the Cocoon picture? As a generator?

Also, is there any URL rewriting functionality in Cocoon sitemap? I saw
redirecting, I would also love to see some rewriting, for example:

  <process uri="myWebApp/*/action=*/*">
    <generate type="turbine" src:url="screen/{1}/action/{2}/{3}" />
  </process>
(As I have never written any regular expression before, then the example
is totally incorrect from the regexp point of view. However, I hope it
shows where I'm aiming at...)

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. (Then I would also have to write my own version of
DynamicURI in Turbine, but that's my problem).

For example, I request
"/myWebApp/myScreens.myScreen/action=myActions.myAction/myParamName=myPa
ramValue" and Cocoon would rewrite this into
"screen/myScreens.myScreen/action/myActions.myAction/myParamName/myParam
Value" and give this URL to Turbine for further processing.
Is this realistic?

Neeme

Re: Cocoon2 Design

Posted by Stefano Mazzocchi <st...@apache.org>.
Neeme Praks wrote:
> 
> > -----Original Message-----
> > From: Giacomo Pati [mailto:giacomo@simba.pwr.ch]
> > Sent: Monday, May 29, 2000 6:59 AM
> >
> > Many week ago I had the same thoughts. If you want to
> > integrate Cocoon
> > into Turbine you are at Jetspeed (Kevin has that already
> > done). If you
> > want to integrate Turbine into Cocoon (seems the better
> > aproache to me)
> > you have to rewrite some core functionality of Turbine to let'em spit
> > out XML.
> 
> I also feel better about
> 1. integrating Turbine into Cocoon
> 2. integrating Jetspeed also into Cocoon ;-)
> 
> Following all the sitemap development, it really starts to look
> promising and I would love to use all the power of sitemap while
> combining it with Turbine and Jetspeed.

Yes, that's the deal.

> I have some ideas, but I'm having hard time imagining how exactly
> Turbine would fit in the Cocoon equation...

Same here... unfortunately...
 
> 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...
 
> 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 don't think using Turbine as a Cocoon component would work...
 
> Also, is there any URL rewriting functionality in Cocoon sitemap? I saw
> redirecting, I would also love to see some rewriting, for example:
> 
>   <process uri="myWebApp/*/action=*/*">
>     <generate type="turbine" src:url="screen/{1}/action/{2}/{3}" />
>   </process>

well, what can I say, I don't know why you would do such a thing... but
probably this is part of the problem.

> (As I have never written any regular expression before, then the example
> is totally incorrect from the regexp point of view. However, I hope it
> shows where I'm aiming at...)

No, the _default_ matching syntax uses wildcards, you have to place
rule="regexp" to make it behave as regular expressions.

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

> (Then I would also have to write my own version of
> DynamicURI in Turbine, but that's my problem).
>
> For example, I request
> "/myWebApp/myScreens.myScreen/action=myActions.myAction/myParamName=myPa
> ramValue" and Cocoon would rewrite this into
> "screen/myScreens.myScreen/action/myActions.myAction/myParamName/myParam
> Value" and give this URL to Turbine for further processing.
> Is this realistic?

I have no idea!

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?

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.

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?

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.

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.

Well, it's too early to tell. Let's get things working with Cocoon2 and
solutions will provide themselves.

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