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
