Michael Hartle wrote:
> - Does this mounting also apply to "non-URI-visual" blocks in your
> vision ? Some blocks expose themselves as web applications, some provide
> features for others, but are not useful seperately, like skins or
> "webapp language/i18n packages" or the like.
Oh, great point. Yeah, I think it's entirely possible to have a block
without a sitemap/flowmap definition, thus 'headless' or 'detached' from
the URI space. Yes, that shouldn't be a problem at all.
> - Does mouting on a specific URI point speak of the public/web URI space
> ? As we can have pipelines that are internal-only, a similar feature to
> a block might extend that thought.
Well, this should be accomplished with the sitemap/flowmap syntax, as we
do it today. I don't see the need for the block to explicit this
someplace else.
But I'm more than open to suggestions here.
> > 3) These Cocoon Blocks contain file resources (raw or precompiled) and
> >compiled bytecode (as individual classes or JAR libraries).
> >
> Each block brings it's own Jar's along?
Yes, exactly.
> Would something like a
> "library" Cocoon Block containing JARs, generators and the like make sense ?
Hmmm, I wouldn't want to make it possible to install Cocoon without
blocks and without functionality because it would make it harder to have
a 'default set' of pipeline components (and a harder time for people to
learn cocoon).
But it definately makes sense to have blocks for different
functionalities that are optional (means: not part of the *core*).
> >if the block-based URI is used in non-namespaced syntax (for example, in
> >the flowmap), an API-based solution will be provided.
> >
> Declaring a namespace prefix for resolving role ambiguities looks a bit
> like a hack;
I know, I know, but I couldn't find anything better and I didn't want to
delay the RT for that :)
> if there is only one ambigious block role per
> map:generate/map:transform, we might as well use an attribute called
> role which would allow this "role override" feature.
Yeah, that would work. Good idea.
> A thought, when there is a role ambiguity, it will happen across the
> whole sitemap/flowmap, right ? So anyone developing in this situation
> will start to add xmlns:role/role to resolve block role name clashes at
> map:generate/map:transform-level, which does not sound right to me as it
> is too late. If we somehow added a block role resolution like
> <xmlns:some="thing"> does it for <some:test/> (perhaps in a section to
> the sitemap/flowmap or a seperate file), developers can have role names
> in their Cocoon Blocks resolved as they need in a consistent manner, and
> I guess we could handle block(role)-type URLs more easily in the
> SourceResolver than with the xmlns:role/role-attribute approach.
Gosh, I think I lost you here. sorry :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
