Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Vadim Gritsenko" <vadim.gritsenko@verizon.net>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Views and RE: [VOTE] Retuning Sitemap Implementation
Date: Mon, 14 Jan 2002 08:32:32 -0500
Message-ID: <013101c19cff$ec0e53c0$90a4558b@vgritsenkopc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-reply-to: <3C42A495.4050607@anyware-tech.com>
Importance: Normal

> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> 
> Vadim Gritsenko wrote:
> 
> >>>>3. Token expansion is allowed for all attributes.
> >
> > Done; yet there is an issue with the views, labels, and
> > map:generate|serialize|transform's type attribute. The issue is how
to
> > determine label of the particular component if at compilation time
name
> > of the component is not known (because of substitution).
> 
> Sorry to jump in lately (I have hard times to follow the list), but
I'm
> not sure it desirable to allow substitution in component types and
view
> labels.

I tend to agree with you... btw, labels are not substituted - because
(in part) that they are allowed in <map:components> (where no
substitution possible).

 
> This could lead to very obscure sitemaps (refer also to "dynamic
> sitemap" Stefano is strongly against), and since source/parameters for
> sitemap statements often are component-specific, I don't see any real
> functional use for this.

One could come up with the example of usage; but I also do not think
that this functionality is required.

 
> > Thinking about views, why it is necessary to declare views and
> > component's labels in every sub-sitemap? If first is just
inconvenience,
> > second poses more serious treat: every sub sitemap dealing with
views
> > must define own pool of components (read: use (sometimes: lots of)
> > memory), leading to scalability issues. I think there is need to
come up
> > with the mechanism to lookup view labels on run-time. Any ideas?
> 
> This could be achieved by a using a specialized ComponentSelector that
> holds the labels for each component. But this means the sitemap is no
> more self-contained (views behaviour can depend on the parent
sitemap).
> 
> 
> > And I have another view-related question: what should be the correct
> > view behavior for the following sitemap fragment:
> >
> > <map:generators default="file">
> >   <map:generator type="file" src="..." label="content"/>
> > <map:generators>
> > ...
> > <map:generate src="data"/>
> > <map:transform src="data2page" label="content"/>
> > <map:serialize/>
> >
> > Now it seems invokes view right after generator.
> 
> Jumping to a view occurs at the first statement having the label the
> view refers to, i.e. the generator in this case.

Shouldn't it be called after transformer? Or, if I want it to be after
transformer, I have to do something like this:

<map:generators default="file">
 <map:generator  name="file" src="...FileGenerator" label="content"/>
 <map:generator  name="file-nolabel" src="...FileGenerator"/>
</map:generators>

<map:match pattern="body-changes.xml">
  <map:generate type="file-nolabel" src="xdocs/changes.xml"/>
  <map:transform src="stylesheets/changes2document.xsl"
label="content"/>
  <map:transform src="stylesheets/document2html.xsl"/>
  <map:serialize/>
</map:match>

And this solution leads to issue #1: scalability problems. I'm just
imagining something like www.mycgiserver.com (thousands of users) on one
instance of Cocoon 2. It's a waste to allow every user have own pools;
and every user should have an ability to declare own labels. This leads
me to opinion that concerns are overlapping. Shouldn't it be possible to
declare labels without declaration of new components?

What do you think?

Vadim


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