cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerard van Enk" <gerard.van....@eo.nl>
Subject RE: [RT] "To Cocoon2 and beyond" :)
Date Sun, 27 Feb 2000 15:41:32 GMT
> > > 4) Internal logging.
> > >
> > > Well, this is in the Cocoon1 todo list but I'll implement it in
> > > Cocoon2... I saw the IBM Log4j package and sounds pretty good. Another
> > > option would be to use Avalon's Omero... we'll see.
> > >
> >
> > If we use the Avalon framework we can plug them in easily, isn't it?
>
> Yes, but I don't know if this will be soon enough.

Won't this be ready when Cocoon 2 is ready (or isn't that soon enough ;-) )

> > >
> > > Anyway, Cocoon can do two things:
> > >
> > >  a) use the RSS info with user preferences to create specific
> collection
> > > of resources (sort of a portal building toolkit, which is what the
> > > JetSpeed project is all about)
> >
> > Are we going to invent JetSpeed again???? Or are we going to integrate
> > Jetspeed with Cocoon???
>
> Yes. Both JetSpeed and Turbine are trying to incorporate Cocoon
> capabilities into them... I think they can't possibly do this without
> loosing much of the functionality, expecially the sitemap.
>
> So I'll push to go the other way around: reimplement JetSpeed on top of
> Cocoon.
>

I agree on this (but will the JetSpeed developers also agree on this???)

> > I think here's a big opportunity for Avalon, just make Jetspeed services
> > Avalon-Components of the Block Jetspeed and Cocoon can use it (if Cocoon
> > uses Avalon). Or is this not the way to go????
>
> Well, actually, there is nothing that JetSpeed does as a functionality
> that Cocoon cannot do by itself. JetSpeed is a complex servlet, if you
> wish, a portal-toolkit. I'd like to create web applications on top of
> Cocoon using JetSpeed code but moving it over Cocoon.
>
> I also believe this will be much easier to implement and manage.
>
> > >
> > >  b) generate the RSS info out of pages contained inside out of RDF
> > > metainformation.
> > >
> > > While point b) doesn't require any special logic (just a wise
> knowledge
> > > of the DTDs involved), point a) requires at least some
> > > ProducterFromURL... but how do we create a page out of a collection of
> > > different resources coming from different places?
> > >
> >
> > I like b, now only finding a way to do this.....
>
> Simpler than what you think: do an XSLT stylesheet for you news DTD with
> contained RDF information. :)

Ok, you got me there!!!!

>
> > > 5) Template Driven Publishing
> > >
> > > Which leads us to the my main concern: real life publishing.
> > >
> > > All my experience as web designer/engineer comes from content-driven
> > > publishing and you can tell from what Cocoon is like today.
> > >
> > > But people coming from different publishing areas
> (newspapers) know that
> > > is the "layout" of the page that drives the process, not the content.
> > >
> > > Layout is not style. Layout is about partitioning a 2d space
> into areas
> > > and assigning those areas to particular content generators.
> The Turbine
> > > framework includes this in detail, but it's limited to a web-oriented
> > > layout due to HTML constraints.
> > >
> > > Now, let us suppose you want to create your web site on a
> piece of paper
> > > to show your boss. What do you do first?
> > >
> > > You draw rectangles! Here goes the logo, here the news, down here the
> > > counter, the sitebar with the slashdot news, the weather
> forecast for my
> > > town, up on the left the links to the other resources...
> > >
> > > You're a programmer, right? You know nothing about style, you can't
> > > draw, you can't even think of cool graphics or icons or those
> things...
> > > but you _do_ see how the layout should look like. You know this by
> > > experience, you've been surfing the net forever and you know where to
> > > place the right information... maybe not which font or color or
> > > background, but you know what should go where.
> > >
> > > Everybody does.
> > >
> > > Layout driven publishing is the design pattern that emerged after
> > > -hundreds- of years of newspaper publishing. Should the digital age
> > > throw it all away? No f....ing way, dude!
> > >
> > > So, the question is: is Cocoon ready for layout-driven publishing? yes
> > > and no.
> > >
> > > I explain: the main question is "is the web ready for layout-driven
> > > publishing?", the answer is "almost".
> > >
> > > Let us suppose for a moment we have a Layout Description
> Language (LDL).
> > > This language is what drives the page construction process.
> For example:
> > >
> > > <l:page xmlns:l="layout" xmlns:c="cocoon">
> > >  <l:table>
> > >   <l:row>
> > >    <l:item width="100%">
> > >     <c:generator c:type="url" c:src="logos/logo.nrg"/>
> > >     <c:namespace prefix="nrg" url="http://cocoon/dtd/nrg"/>
> > >    </l:item>
> > >   </l:row>
> > >   <l:row>
> > >    <l:item width="30%">
> > >     <c:generator c:type="dir" c:src="."/>
> > >     <c:filter c:type="xslt">
> > >      <c:parameter c:name="stylesheet" c:value="dirs2links.xsl"/>
> > >     <c:filter/>
> > >     <c:namespace prefix="link" url="http://cocoon/dtd/link"/>
> > >    </l:item>
> > >    <l:item>
> > >     <c:generator c:type="file" src="*"/>
> > >     <c:namespace prefix="doc" url="http://cocoon/dtd/doc"/>
> > >    </l:item>
> > >   </l:row>
> > >  </l:table>
> > > </l:page>
> > >
> > > which represents a layout-centric view of the current xml.apache.org
> > > layout.
> > >
> > > Note, in fact, that there is a big difference between a layout and a
> > > skin. A layout does not have styleinformations. In fact
> percentage-based
> > > item width is not style, but layout.
> > >
> > > True, one could easily picture another separation done like this:
> > >
> > >  <page>
> > >   <topbar/>
> > >   <sidebar/>
> > >   <content url="*"/>
> > >  </page>
> > >
> > > then then apply a "layoutsheet" to tell how much of the page should be
> > > occupied by the sidebar.
> > >
> > > The question: is the above possible in Cocoon2? yes, it is.
> > >
> >
> > Can't this be done right now with XSP?
>
> Sort of... but not like I'd like it to be. I'll think at what needs to
> be added to the spec to make it smoother.
>
> > Do we need to make some kind of standard layout-template
> definition and the
> > XSP's to use them???
>
> No, we need a way to hardwire other documents into XSP, and to make the
> modifiedSince() method behave nicely in respect of the included
> documents... it could be done today, but it should be easier and more
> portable... anyway it's too blurry on my head.. I nead more thoughts on
> this.
>

I'm not sure if I understand what you're saying with "hardwire other
documents into XSP"?

> > > sheesh, that was long.
> > >
> > > Sorry about that, but I hope to have given you food for
> thought :) take
> > > care and digest it slowly.
> > >
> >
> > Yeah...I will, I hope I didn't say anything stupid, because
> this is to much
> > information for my brain on a saturday evening ;-)
>
> Nothing is stupid. Even the most out-of-context questions can trigger
> idea generation in others... never underestimate the power of noise, as
> Darwin, Turing and Shannon showed us in different fields.

Yeah, but on a saturdaynight???

Gerard


Mime
View raw message