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] Finishing the first phase of block design
Date Fri, 10 Oct 2003 08:52:34 GMT

On Friday, Oct 10, 2003, at 04:01 Europe/Rome, Geoff Howard wrote:

> 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
>
> ...
>
>>>> 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?
>> This might suggest the concept that private is the location of all  
>> the things that are private so
>>  private/lib
>> means "I have libraries in the private section", so maybe I can put  
>> something else as well to have it protected? while
>>  lib/private
>> means "these are the private libraries"... but doesn't say anything  
>> about non-lib things. I still like this approach better, even if it  
>> moves away from the WAR paradigm (which is not a big deal, IMO, since  
>> blocks are different enough already)
>
> Ok, that's a good point.  I have a parallel concern that something like
>
> COB-INF/classes/com/mypackage/whyisntitfound/NotFound.class
>
> or
>
> package public.com.myconfused.package
> public Class StillNotFound {...
>
> will pop up regularly on the users list.

hmmm, don't think so, don't see many users actually adding their own  
single classes to those blocks and then deploy. I think they will put  
their prepackaged jars in there. but hey, you might be right.

> One more idea to try to avert potential confusion.
>
> COB-INF/private-lib/
> COB-INF/private-classes/
> COB-INF/public-lib/
> COB-INF/public-classes/
>
> ?

I'm -0 on this, don't see the need, but I see your point.

>>> - 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?
>
> sitemap references:
> block:external-skin:/stylesheets/news2html.xslt
>
> block manager has external-skin ->  
> http://mycompany.com/skins/corporate/34.3.345
>  -> extends ->
> http://yetanothercompany.com/skins/fancy/1.2.2
>
> checks WEB-INF/blocks/384938958499/sitemap.xmap (by the way, the Cob  
> samples at the wiki don't have sitemaps for the skins blocks which  
> would presumably need them to expose their xslt in the example right?)

no, if the sitemap is not explicitly exposed, then the block manager  
will default to sitemap.xmap in the root. if *that* is not present,  
than the block does not expose resources and the block: protocol would  
return a 404 or trigger an exception.

> If that sitemap doesn't override /stylesheets/news2html.xslt, every
> pipeline in that sitemap needs to be checked _then_ block manager goes  
> on to  
> WEB-INF/blocks/how-does-the-block-wiring-handle-blocks-extended-but- 
> not-otherwise-used/sitemap.xmap
>
> if there are several levels of extension, this could be a long process.

true

> But now a worse thought comes to mind:
>
> suppose http://yetanothercompany.com/skins/fancy/1.2.2 has defined
>
> <map:match pattern="stylesheets/*.xslt">
>   <map:read src="styles/{1}.xslt"/>
> </map:match>
>
> but http://mycompany.com/skins/corporate/34.3.345 only wants to
> override /stylesheets/news2html.xslt and /stylesheets/another.xslt
>
> if it is allowed it do
>
> <map:match pattern="stylesheets/*.xslt">
>   <map:read src="mystyles/{1}.xslt"/>
> </map:match>
>
> then we must make the block manager and sitemap engine have a new  
> behavior: if a match exists, but the source is not actually found,  
> proceed to the super-block etc.

nono, inheritance works as the URI matching level, not at the resource  
level. If you match the URI and then you failed to provide a resource,  
you get a 404. So, at least, you know where you are.

> That's a mess, but so is having to set up a whole series of identical  
> pipelines for every image, stylesheet, etc you need to override from a  
> super-block, isn't it?

You can use regexp matching. It's not that bad.

I don't picture extension to change *everything* inside the block, but  
just a few details. anti-patterns will emerge and verbosity of the  
sitemap would reduce the change of abusing block extension.

> Now, perhaps this could be handled in other ways by using selectors  
> instead of wildcards in matchers, but this could make writing a block  
> a little finicky.

i think regexp matching is perfect for this

>  If we decide to go with existing semantics with no explicit list of  
> provided or overridden resources, we'll need to think through and very  
> clearly document best practices that are not onerous. On users for  
> whom this may be a very mindbending concept.

True, but as I said, it could have a useful side effect: you use  
extension only when it really makes sense or forces you to think a  
better (delegation oriented) refactoring pattern (extension is cool,  
but should be used much less than delegation)

> Ok, there are several thoughts in all the above.  Here they are with  
> what is in my mind the state of the discussion:
>
> 1) Resource access
> "Should resources be provided via pipeline, via standard file i/o, or  
> a combination of both?"
>
> I think we now all agree that pipeline-only is the way to go.

cool

> 2) Resource visibility
> "Should some ability to distinguish between public and private  
> resources/pipelines exist?"
>
> Yes, and @block-access="public" handles this well presuming that  
> discussion can be considered settled. (but see below)

all right

> 3) Explicit resource uri's
> "Should exposed resource (pipeline) uri's be declared explicitly?"
>
> This is where I still have some reservations as begun above in the  
> not-found/fallback example.
>
> <map:match pattern="stylesheets/*.xslt">
>   <map:read src="styles/{1}.xslt"/>
> </map:match>
>
> Is convenient to write, but may be inconvenient to use for block  
> users, extenders, implementers, and the BlockManager (code).  Perhaps  
> the first  can be taken care of with human readable documentation  
> (though I fear what the cocoon blocks will have in this respect).   
> Perhaps the second is unfounded.  I'm not convinced of either of those  
> and think it merits further thinking.
>
> A possible solution:
> Rather than disallowing wildcards, perhaps a part of block.xml could be
>
> <resources>
>   <uri>/stylesheets/news2html.xslt</uri>
>   ...
> </resources>
>
> Maybe that'd be a pain but it'd leave no guessing.  Maybe:
>
> ...
> <extends block="http://yetanothercompany.com/skins/fancy/1.2.2">
>   <uri>/stylesheets/news2html.xslt</uri>
> </extends>
> ...
>
> Would be better?  It would get rid of the fallback problem.

I don't think we have a fallback problem if we stick to the concept  
that matching simply follows the sitemap rules and nothing else. If it  
works today and nobody complains I don't see why it should work there  
as well.

--
Stefano.


Mime
View raw message