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 Thu, 01 Jun 2000 18:19:25 GMT
Neeme Praks wrote:
> 
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > Sent: Wednesday, May 31, 2000 12:19 AM
> >
> > > 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.
> 
> can you give some example of this?

see below

> > > 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.
> 
> I like the idea of "internal redirection", this is basically what I like
> about Turbine actions: that I can return a different page based on my
> specific logic.

right
 
> Actually, now I start to see a little bit, what you meant with "Turbine
> Actions look a lot like Cocoon2 matchers". But I still would love to see
> this exemplified.

 <components>
  ...
  <tester type="user" class="org.apache.cocoon.tester.UserTester">
   <param name="database-url" value="...."/>
   <param name="database-password" value="...."/>
   ...
  </tester>
 </components>
  
 <processing uri="/bugs/home">
  <if test="user is authorized">
   <generator type="xsp" src:local="./xsp/home.xsp"/>
  </if>
  <else>
   <generator type="xsp" src:local="./xsp/login-form.xsp"/>
  </else> 
  <filter type="xslt" src:local="./styles/simple2html.xsl"/>
  <serializer type="html"/>
 </process>

isn't the "tester" component similar to a Turbine action?

But not equal because it includes logic that "tests" the state, the
action concern is given to the sitemap.

> > 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 :)
> 
> ;-)
> And this is almost the target we are aiming at... but I think it will be
> easier just to take parts of Turbine and integrate them to Cocoon that
> to rewrite whole Turbine into XTurbine (and the end result would still
> be even bigger hack than now).

I totally agree. But I don't think Jon would like that :)
 
> > 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.
> 
> yep, I agree with you... but I still don't have a clear picture how
> sitemap would replace Turbine. As I already said, I would love to see an
> example of this...

Hope the above is helpful.

In case it's not, I probably misunderstood completely Turbine actions
and if it is so, please, tell me :) (I'm never used Turbine directly)

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