cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerard van Enk" <>
Subject RE: [RT] "To Cocoon2 and beyond" :)
Date Sat, 26 Feb 2000 23:04:50 GMT
> 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?

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

> 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
> (
> <?xml version="1.0"?>
> <rdf:RDF
>  xmlns:rdf=""
>  xmlns="">
> <channel>
>  <title>Mozilla Dot Org</title>
>  <description>the website</description>
>  <link></link>
> </channel>
> <item>
>  <title>XPInstall Newsgroup</title>
>  <link></link>
> </item>
> <item>
>  <title>Open Source PKI Code Released</title>
> <link>
> 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 under control.
> If you look at
> 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???
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????

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

> 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 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
> 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?
Do we need to make some kind of standard layout-template definition and the
XSP's to use them???

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


View raw message