cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: [RT] Finishing the first phase of block design
Date Fri, 10 Oct 2003 09:04:54 GMT


On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:

>
> On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
>
> > Stefano Mazzocchi wrote:
> >
> >> I have updated the block design documents on the wiki. Changes were:
> >
> > ...
> >
> >> A few things are left to decide:
> >>  1) the block metadata information in the block.xml file
> >>   see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
> >>  2) how blocks expose classloading to other blocks
> >>                              - o -
> >> Descriptive Block metadata
> >> --------------------------
> >> The descriptive block metadata that we currently include is:
> >>  <name>***</name>
> >>  <description href="...">***</description>
> >>  <license href="..."/>***</license>
> >>  <author href="...">***</author>
> >
> > +1
> >
> > Andreas suggested version number which is really handled already in
> > the block id and release date.  I think a date though may be a useful
> > additional piece of info.
>
> Good point.

IMHO, I would try first a solution, which doesn't introduce a new
descriptor. In a know german XML magazin, Cocoon was descriped a
configuration hell, and as a anti pattern using XML as
configuration format.

So my proposal would be to start small, and if there isn't a way
to come forward with the current possibilities, then
we could introduce a new descriptor file beside
cocoon.xconf/sitemap.xmap/web.xml etc.

> >> Exposing classes
> >> ----------------
> >> Stephen proposed to separate the classes to expose in a different jar
> >> and expose that. I like this. It's simple and effective.
> >> But instead of declaring classloaders or classpaths in the blocks, I
> >> propose to extend the block FS layout so that we have
> >> for individual classes and resources:
> >>  /classes
> >>  /classes/public
> >>  /classes/private
> >> for jars:
> >>  /lib
> >>  /lib/public
> >>  /lib/private
> >
> > Hmmm.  That is quite different than what one would expect from the WAR
> > paradigm, no?  Would
> >
> > COB-INF/[classes|lib]
> > COB-INF/public/[classes|lib]
> >
> > or
> >
> > COB-INF/private/[classes|lib]
> > COB-INF/public/[classes|lib]
> >
> > be any better?

Could you please explain, why we need to separate the classes and lib into
private and public. For the developers POV, it will make the development
more complicated, and doesn't see any benefit.

> > Exposing Resources
> > ------------------
> >
> > I'm adding this because my brain is still a little unsure about this.
> > So far, we've said that file resources (an xsl for example)
> >
> > 1) need to be exposed via a sitemap pipeline, even if only by a reader
> > 2) are not anywhere declared explicitly (except in the pipeline of
> > course)
> > 3) are not distinguised from resources meant to be private by any
> > formal semantics, though this information could be conveyed
> > human-to-human in any block docs (blocs? blockumentation? ;) ).
> >
> > Here are my oustanding questions:
> >
> > - Will we regret requiring the overhead of pipeline setup (runtime I
> > mean) for blocks which expose a great deal of otherwise static
> > resources?
>
> could be. remember though that the block: protocol will be caching
> friendly, so we might even gain performance.
>
> > - Not found resources will have to go through every pipeline to
> > determine that it's not found.  With fallback behavior due to
> > polymorphism this gets worse.
>
> I fail to see this, can you explain why you think this is the case?
>
> > - Will not explicitly declaring which resources are meant to be public
> > cause trouble for block implementors and extenders?
>
> ?? well, in the sitemap I can be very precise on what I want to expose.
> and everything else is not exposed. the sitemap is like a virtual file
> system description, powerful enough to describe all possible systems.
>
> If you have
>
> <pipeline block-access="public">
>   <match pattern="**">
>    <read src="public/{1}"/>
>   </match>
> </pipeline>
>
> than the contract moves at the file system level, but that's up to you
> to decide.... and a block extender can do
>
> <pipeline block-access="public">
>   <match pattern="stylesheet/layout2page.xslt">
>    <generate type="sql" src="layout.xml"/>
>    <transform src="layout2stylesheet.xslt"/>
>    <serialize type="xml"/>
>   </match>
> </pipeline>
>
> to provide extension that is procedural (but without exposing, for
> example layout.xml and layout2stylesheet.xslt which are just used
> internally)

Yes, I like that. This is the solution, which comes first in my mind.

Stephan.


Mime
View raw message