cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] "To Cocoon2 and beyond" :)
Date Sun, 27 Feb 2000 01:18:09 GMT
Gerard van Enk wrote:
> 
> > NOTE: [RT] stands for "random thoughts", so skip this mail unless you
> > really want to. You have been warned.
> >
> 
> I love these "random thougts"........ ;-)
> 
> > 2) Enterprise taglibs for XSP
> >
> > the object -> relational binding logic sucks. This is evident to
> > everyone that ever wanted to push an object into a database. People are
> > talking about OODBMS... I still have to see one that does what I want,
> > but it seems that EJB is what we need.
> >
> > Something as simple as
> >
> >  ...
> >  <ejb:bean name="shopping-cart">
> >   <ejb:set name="itemĀ°>
> >    <form:get name="item"/>
> >   </ejb:set>
> >  </ejb:bean>
> >  ...
> >  <ejb:commit bean="shopping-cart"/>
> >
> > now, _THAT_ is something useful... not the SQL crap we have to embed
> > into our logic. Sure, if you already have relational data and you want
> > something out of it, use donald's sql taglib and you'll be set for
> > life... but like if you want to use your DBMS for store ACID
> > transactions out of your pages... hmmmm, sql is expensive thing to do
> > and, in my opinion, too different from the highly object-oriented Cocoon
> > world.
> >
> 
> Yes, but we can use something like the above and use SQL at a lower level if
> we need it. Isn't this the whole idea about XSP, hide the lowlevel logic to
> the people who using XSP-tags to access content and logic?

yes, you're right. In fact the JCP process will try to create standard
taglibs for JSP... I suppose we'll simply use them. (both Ricardo and I
are in the expert group)
 
> > 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.
 
> > Anyway, internal logging will be a must when the pipeline will be in
> > place.
> >
> > 5) RDF+RSS/CDF support.
> >
> > Like for SOAP, the Cocoon architecture is XML-schema-neutral from the
> > ground up so you can do whatever you want with all the schema you wants.
> > But the RDF+RSS/CDF couple is _very_ interesting (see the JetSpeed
> > project).
> >
> > A breif explaination:
> >
> > RDF stands for Resource Description Framework and it's a W3C
> > Recommendation issued three days ago over more than 2 years of work!!!
> > RDF is one of the oldest XML research projects and, let me tell you, one
> > of the most brilliant.
> >
> > RDF is not even a language, but a framework, a namespace that should be
> > intermixed with your own namespaces (whatever you want, even XHTML) to
> > specify some information _about_ the content.
> >
> > things like "document abstract, key words, authors" and the like should
> > be indicated with the proper elements, but some RDF meaning should be
> > added to allow, say, indexers or crawlers to retrieve information about
> > them.
> >
> > RDF specifies "metadata", that is "data about data". Just like XML is a
> > "meta-language", a "language for languages".
> >
> > RSS is Netscape's "Rich Site Summary" and CDF is Microsoft's "Channel
> > Description Format".
> >
> > Both do the same thing: create sort of simple indexing about the site
> > they refer to. For example, let's look at the Mozilla automatic RSS file
> > (http://www.mozilla.org/news.rdf):
> >
> > <?xml version="1.0"?>
> > <rdf:RDF
> >  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> >  xmlns="http://my.netscape.com/rdf/simple/0.9/">
> > <channel>
> >  <title>Mozilla Dot Org</title>
> >  <description>the mozilla.org website</description>
> >  <link>http://www.mozilla.org</link>
> > </channel>
> >
> > <item>
> >  <title>XPInstall Newsgroup</title>
> >  <link>http://www.mozilla.org/news.html</link>
> > </item>
> >
> > <item>
> >  <title>Open Source PKI Code Released</title>
> >
> > <link>http://www.mozilla.org/projects/security/pki/src/download.ht
> > ml</link>
> > </item>
> > </rdf:RDF>
> >
> > as you see, it's pretty easy to create a simple HTML sidebar from this
> > file... your way to keep mozilla.org under control.
> >
> > If you look at
> >
> >  http://my.userland.com/stories/storyReader$235
> >
> > there are hundreds of such RDF+RSS news services listed. A real gold
> > mine. Slashdot, Freshmeat and all the key information sites can be found
> > there. Not as intrusive as PUSH technology, but a great amount of
> > information.
> >
> > 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 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. :)
 
> > 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 picture the above layout transformed into XSP after authoring and then
> > compiled into a generator.
> >
> > note that the above does not indicate _how_ the page should be
> > formatted!!!! In fact, the above does not collision with the sitemap,
> > rather the opposite: is simplifies the sitemap operation by doing
> > further separation of contexts inside the content-creation context.
> >
> > Sure the line gets blurred a little, but I'm confident something like
> > this will be extremely powerful once we have a good FO+SVG+NRG renderer
> > in place.
> >
> > yes, because everything should be formatted by FOP! The best thing would
> > be to use formatting objects _always_ as the output format and have
> > formatters taking care of the HTML generation automatically, depending
> > on client properties.
> >
> 
> I think this is a great idea!
> 
> >
> > 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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

Mime
View raw message