cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [RT] Finishing the first phase of block design
Date Fri, 10 Oct 2003 16:46:03 GMT
Stefano Mazzocchi wrote:
> 
> 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:

...

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

Ok, if no one else sees the need I'm fine to move forward as is.  As a 
final wild idea, the Avalon meta-info project might help here.

...

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

Ok, I see that.  This will be another thing that should be clear in the 
"idiots guide to authoring blocks" ("blocks for blockheads"?).  Be 
careful to match only what you intend to override by extension.

Geoff


Mime
View raw message