Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>>Attaching a label to a component (e.g. a generator) makes this label
>>implicit for _all_ uses of that component. This is useful when the kind
>>of information represented by the label is always produced by that
>>component, since this avoids adding this label everywhere in the
>>pipeline where this component is used.
>>
>>In Cocoon's documentation sitemap, the "content" label is associated to
>>the document DTD, and this is _most often_ produced from files, hence
>>the label "content" on the "file" generator. Now this is only _most
>>often_ and not _always_ : todo.xml, faq.xml, changes.xml aren't in the
>>document DTD and need an initial transformation, and only after this
>>transformation can they can have the "content" label, as in the
>>following extract from the doc sitemap :
>>
>> <map:match pattern="body-todo.xml">
>> <map:generate type="file-nolabel" src="xdocs/todo.xml"/>
>> <map:transform src="stylesheets/todo2document.xsl" label="content"/>
>> <map:transform src="stylesheets/document2html.xsl"/>
>> <map:serialize/>
>> </map:match>
>>
>>Since "file" generator has a "content" label, it cannot be used here,
>>otherwise "todo2document.xsl" isn't applied when the view is requested.
>>So a solution was to define a new "file-nolabel" generator, which has
>>the *exact same definition* as the "file" generator but doesn't have the
>>label.
>>
>>The problem with this approach is that only 3 files in the whole docs
>>have this special requirement of an initial transformation, and this
>>requires to create a new component and all the associated overhead :
>>duplicate configuration, duplicate handler in the component selector and
>>duplicate object pool. As Vadim pointed out, do that in a shared Cocoon
>>installation where every user can have its sitemap and you can buy some
>>more RAM !
>>
>>So my proposal was to allow to locally "substract" a label defined at
>>the component level. The above snippet would then become :
>>
>> <map:match pattern="body-todo.xml">
>> <map:generate type="file" src="xdocs/todo.xml" label="-content"/>
>> <map:transform src="stylesheets/todo2document.xsl" label="content"/>
>> <map:transform src="stylesheets/document2html.xsl"/>
>> <map:serialize/>
>> </map:match>
>>
>>This avoids the overhead of declaring a new generator and clearly shows
>>that we have a local modification of the label globally attached to the
>>"file" generator.
>>
>>Is it more clear ? And if yes, what do you think ?
>>
>
>Ok, perfectly clear.
>
>Now, please, tell me: why is the other solution we proposed to this
>problem (that is: exit on the 'last' conten view, not the first one)
>wasn't accepted. I still think it's the most elegant solution.
>
>Sure it is harder to implement, but we never did designed forced by
>implementation difficulties and I don't see why we should start now.
>
Let me put back the explanations I gave to Volker Schmitt, with some
more details. The below sitemap will be used for these details
(high-level structural elements skipped for simplicity) :
<map:view name="content" from-label="content">
<map:transform src="content2html.xsl"/>
</map:view>
<map:resource name="foo">
<map:transform src="foo.xsl" label="content"/>
<map:serialize/>
</map:resource>
<map:resource name="bar">
<map:act type="updatedatabase"/>
<map:transform src="bar.xsl"/>
<map:serialize/>
</map:resource>
<map:pipeline>
<map:match pattern="foobar">
<map:generate src="foobar.xml" label="content"/>
<map:act type="findtype">
<map:call resource="{type}"/>
</map:act>
</map:match>
</map:pipeline>
---oOo---
From a user point of view, knowing when branching will occur can become
a nightmare since you have to crawl all branches that can participate in
a request handling (matchers, selectors, actions, resource calls, etc)
in search for this last label.
In the above sitemap, there's a "content" label on the generator, but
the "foo" resource also has this label. If the last label is used, you
cannot know by reading the "foobar" pipeline if the view will start at
the <map:generate> or not. You have to examine all possible branches
(and in the above case, they're dynamic) to find other places where the
same label is used.
Using the first label makes the behaviour more predictible : if a
labelled statement in the sitemap is reached, then we *know* that the
view starts at this statement.
---oOo---
Implementation will be difficult, as it requires the whole regular
pipeline (the view-less one) to be built before deciding at which point
should occur branching.
I agree that specs shouldn't be constrained by implementations details.
However, we must be aware that this requires some big changes in the
existing pipeline architecture to "break" the regular pipeline at a
point. But the important point here is that we need to fully build the
regular pipeline to know the branching point (see below).
---oOo---
Corollary to the previous point, building the regular pipeline may have
some side effects (e.g. actions) _after_ the branching label, but we
cannot know beforehand that these actions shouldn't have been executed
because they're not in the view.
This is illustrated in the above sitemap : the "bar" resource has an
action that modifies the system state, but since there is no "content"
label in the "bar" resource, the view starts from the generator, that is
*before* the action in the sitemap flow. Should this action be executed
when the view is requested ?
This leads to an interesting question. In "retuning sitemap design" (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101057440717758&w=2),
you classify sitemap statements in two main categories : direct
components (generators, transfomers, etc) and indirect components
(matchers, selectors, actions, etc). How does view handling relate to
this classification ?
In the current definition of views, there is no difference between
direct and indirect components, and the sitemap is executed up to a
matching label that causes a jump to the view. Components after the view
label, both direct and indirect, aren't executed.
If we change the behaviour and branch from the last label, this means
that *all* indirect components of the regular pipeline are to be
executed because they perform the routing in the sitemap and there
execution is therefore required to find the last label.
Is this really what we want ? My opinion is no : this would make
understanding views and predict there behaviour really difficult. Views
are a powerful concept and many users already have difficulties to
master them. Turning them to black magic won't promote their use.
---oOo---
Conclusion (thanks for those who have read all of the above ;)
I consider the label-on-component feature a writing facility to avoid
tedious repetition in the pipelines. The documentation sitemap (with
"file" / "file-nolabel") clearly shows that views are attached to a
particular DTD that exists at some places in the pipelines, and that
attaching their labels to general-purpose components like the resource
generator may not be a good thing : 80% of the uses of that generator
produce the correct DTD, but we need to be able to handle the remaining
20% without sacrificing the writing facility. That's why I suggested
these "substractive labels" to avoid the declaration of a new component
and the associated overhead.
Also, I didn't find in the archive the reasons for this "move to last
label" todo. And I wouldn't be happy if this was proposed as a
workaround for the label-on-component problem. We should not constrain
the definition of views by the bad side-effects of a writing facility.
---oOo---
>>And please don't forget my other post about views in aggregation :)
>>
>
>Sorry, I thought that was sorted out: what's the problem again (I think
>I missed it previously).
>
One-click reminder ;)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101683844805545&w=2
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
