Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C91EB1B.AFF82008@apache.org>
Date: Fri, 15 Mar 2002 13:37:47 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Avoiding Cocoon Thermal Death
References: <3C8F7088.725592E9@apache.org> <3C8F85F1.2000900@hartle-klug.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org