You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/08/07 13:46:04 UTC
Where to put components (Re: cvs commit: ...)
On Thu, Aug 07, 2003 at 12:47:24PM +0200, Juan Jose Pablos wrote:
> jeff,
>
> >>
> >>They do nothing.
> >
> >
> >They act as documentation, and make the subsitemap's interface with the
> >owner sitemap explicit. It's like declaring your dependencies; always a
> >good thing.
>
> IMO it is confused, for status there is not map:readers map:selectors or
> map:resources but you have those entries there.
status.xmap does not use any readers, selectors or resources, so why
should it declare a dependency on any, or define any?
status.xmap does use generators, transformers and serializers, so there
should probably be
<map:components>
<map:generators default="file"/>
<map:transformers default="xslt"/>
<map:serializer type="html"/>
<//map:components>
> > Also, when next someone wants to add a transformer, they can
> >immediately see where to add the component definition, and don't risk
> >incorrectly redefining the default.
> >
>
> But if they want to define the same one, they will try to duplicate as
> it happens (this was how started)
I'm not following. If I see
<map:transformers default="xslt"/>
I know that this subsitemap expects 'xslt' to be defined for it. Why
would I redefine it? If I wanted to, what's wrong with that?
> >Because you are right that duplication is not a good thing. This is a
> >tradeoff. Some components ('xml', 'xslt', 'html' etc) are used
> >everywhere, and their definition is typically very stable. If a
> >component is a) used in multiple places, b) has a stable component
> >definition, then it should go in sitemap.xmap.
> >
> ok,
> so why forrest.xmap and raw.xmap still defining html generators, can see
> my point about getting things tidier?
Yes, there is room for improvement. Since only raw.xmap uses the HTML
generator, it should probably only be defined there.
> when a component definition is move it to sitemap.xmap then users that
> overwrite sitemap will get its site broken, because of that I thought
> that if you put it on sitemap in the first place less you play safe.
Yes I see that. For example, if we defined the HTML generator only in
raw.xmap, and then later moved it to sitemap.xmap, we'd break things.
However, we could always leave a duplicate definition in raw.xmap. The
other way round (moving from sitemap.xmap to a subsitemap) always breaks
things. It is still better to start with a limited scope, and then
expand it if necessary.
--Jeff
> Cheers,
> cheche
>
>
>
Re: Where to put components (Re: cvs commit: ...)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Aug 07, 2003 at 04:34:28PM +0200, Juan Jose Pablos wrote:
> Jeff,
>
> I removed the componets that are not related to submaps. But I would
> like to remove the ones that does not declaring anything, to give you an
> example on status.xml, I would like to remove:
>
> 19d18
> < <map:generators default="file"/>
> 27,29d25
> < <map:transformers default="xslt"/>
> < <map:matchers default="wildcard"/>
> < <map:selectors default="browser"/>
>
>
> You said that they there because "They act as documentation, and make
> the subsitemap's interface with the owner sitemap explicit."
>
>
> 1) If we want to have as documentation, then we can have them under <!--
> comments -->
>
> I removed and test it, and I can not see any change on the behaviour.
>
> Could you elaborate a bit futher on "make an explicit interface?"?
What does the following subsitemap do?
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:pipelines>
<map:pipeline>
<map:match pattern="aaa"/>
<map:generate src="bbb"/>
<map:transform src="ccc"/>
<map:serialize/>
</map:pipeline>
</map:pipelines>
</map:sitemap>
There is no way to tell, because it depends on what the parent sitemap
has declared as the defaults.
If you add:
<map:components>
<map:generators default="serverpages"/>
<map:transformers default="xslt"/>
<map:serializers default="fo2pdf"/>
</map:components>
Then
- You immediately know that 'aaa' is a PDF, 'bbb' is an XSP, and 'ccc'
is an XSLT stylesheet. This is the documentation effect
- Say some day we decide to switch the default transformer from XSLT
to STX. If we handn't explicitly said "ccc is an XSLT" then this
sitemap would quietly fail. But as we've defined it, the sitemap
will work fine if we keep the 'xslt' component, and fail in a
sensible manner if we don't.
--Jeff
> Cheers,
> Cheche
>
>
>
Re: Where to put components (Re: cvs commit: ...)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
I removed the componets that are not related to submaps. But I would
like to remove the ones that does not declaring anything, to give you an
example on status.xml, I would like to remove:
19d18
< <map:generators default="file"/>
27,29d25
< <map:transformers default="xslt"/>
< <map:matchers default="wildcard"/>
< <map:selectors default="browser"/>
You said that they there because "They act as documentation, and make
the subsitemap's interface with the owner sitemap explicit."
1) If we want to have as documentation, then we can have them under <!--
comments -->
I removed and test it, and I can not see any change on the behaviour.
Could you elaborate a bit futher on "make an explicit interface?"?
Cheers,
Cheche
Re: Where to put components (Re: cvs commit: ...)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
Nicola Ken Barozzi wrote:
>
>
> Now, that is not the same thing as now, because we don't want or need a
> generic include mechanism, but a way of *decorating* our sitemap.
>
*decorating*???
>
> Let's talk about what we intend to see before discussing implementation.
>
Wherever is the discussion, I would like to see some examples, it is
easier to understant each other.
Cheers,
Cheche
Re: Where to put components (Re: cvs commit: ...)
Posted by Roger Ackroyd <ap...@ackroyd.freeserve.co.uk>.
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: <fo...@xml.apache.org>
Sent: Thursday, August 07, 2003 2:02 PM
Subject: Re: Where to put components (Re: cvs commit: ...)
> Another need is that to define the sources of the files, that are not
> necessarily on the disk.
>
Is that not a core concept of Maven?. The idea of known local and remote
repositories does not seem a too bad an idea. Can this not be extended to
forrest for all types of files?
Am I being naive?
Roger
Re: Where to put components (Re: cvs commit: ...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 07/08/2003 14.56:
> On Thu, Aug 07, 2003 at 02:24:53PM +0200, Juan Jose Pablos wrote:
...
>>The root problem is the way we overwrite sitemap, and the need for users
>>to overwrite it.
>
> Yes.
Another need is that to define the sources of the files, that are not
necessarily on the disk.
> No idea how to fix this though..?
I still remember a guy that asked to be able to "include" sitemap parts,
because he had different teams working together on the sitemap.
I replied to him that he had to partition the URI space to make it
possible that these teams work on separated spaces. It makes sense, as
they do not need to step on each other just because they defined the
same URI.
Now, that is not the same thing as now, because we don't want or need a
generic include mechanism, but a way of *decorating* our sitemap.
> Maybe the solution is outside Forrest. Perhaps we could write a SAX
> handler that constructs a 'virtual' sitemap by reading the Forrest
> default sitemap, and then adding user-defined parts..
Let's talk about what we intend to see before discussing implementation.
I imagine that we define some "extension" points in the sitemap where we
reckon that users should be able to add definitions, or even override
behaviour. Since we won't change these points, changing sitemaps would
not change the users ones.
How would users use it in practice? Hmmm... I'd want to override a match
for instance, and in case pass it on. I'd also like to be able to insert
extra components in the pipeline, like for example a pre-skinning
transformer, *without* messing with the Forrest-defined pipeline.
Hmmm...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Where to put components (Re: cvs commit: ...)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Aug 07, 2003 at 02:24:53PM +0200, Juan Jose Pablos wrote:
> Jeff,
>
> Jeff Turner wrote:
> >
> >status.xmap does not use any readers, selectors or resources, so why
> >should it declare a dependency on any, or define any?
> >
>
> That is what I am asking you!, on your last change, you added more
> stuff than what I think is needed.
Oh, sorry, I was looking at an old copy (the one you committed), thinking
"what's wrong with that?" ;)
I'll fix this tomorrow unless you get to it first.
> >status.xmap does use generators, transformers and serializers, so there
> >should probably be
> >
> ><map:components>
> > <map:generators default="file"/>
> > <map:transformers default="xslt"/>
> > <map:serializer type="html"/>
> ><//map:components>
> >
> >
>
> But on the last commit you added as well:
>
> > <map:readers default="resource"/>
> > <map:selectors default="browser"/>
>
> and there are a:
>
> <map:resources>
> </map:resources>
>
> If there should not be there, let me know and I will removed them.
Yes you're right, they shouldn't be there. Sorry, seems I rolled back a
bunch of useful changes from your commit.
> >I'm not following. If I see
> >
> > <map:transformers default="xslt"/>
> >
> >I know that this subsitemap expects 'xslt' to be defined for it. Why
> >would I redefine it? If I wanted to, what's wrong with that?
> >
>
> There is nothing wrong with define another transformer, but it is wrong
> if you are going to define the same transformer ( as it happends)
> because that is duplication.
It's not _defining_ a transformer at all. It's _declaring_ that this
sitemap expects the default transformer to be 'xslt'. The 'xslt'
transformer is defined in the root sitemap.
> Belive or not, this code produces confusion, it you want to leave as
> documentation then let's use <!-- coments -->. I do not like code that
> does not anything but confuse :-)
>
>
> >
> >Yes I see that. For example, if we defined the HTML generator only in
> >raw.xmap, and then later moved it to sitemap.xmap, we'd break things.
> >However, we could always leave a duplicate definition in raw.xmap. The
> >other way round (moving from sitemap.xmap to a subsitemap) always breaks
> >things. It is still better to start with a limited scope, and then
> >expand it if necessary.
> >
>
> The root problem is the way we overwrite sitemap, and the need for users
> to overwrite it.
Yes.
No idea how to fix this though..?
Maybe the solution is outside Forrest. Perhaps we could write a SAX
handler that constructs a 'virtual' sitemap by reading the Forrest
default sitemap, and then adding user-defined parts..
> Can we have an external xml file with all definitions?
Not as far as I know.
--Jeff
>
> Cheers,
> Cheche
>
Re: Where to put components (Re: cvs commit: ...)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
Jeff Turner wrote:
>
> status.xmap does not use any readers, selectors or resources, so why
> should it declare a dependency on any, or define any?
>
That is what I am asking you!, on your last change, you added more stuff
than what I think is needed.
> status.xmap does use generators, transformers and serializers, so there
> should probably be
>
> <map:components>
> <map:generators default="file"/>
> <map:transformers default="xslt"/>
> <map:serializer type="html"/>
> <//map:components>
>
>
But on the last commit you added as well:
> <map:readers default="resource"/>
> <map:selectors default="browser"/>
and there are a:
<map:resources>
</map:resources>
If there should not be there, let me know and I will removed them.
> I'm not following. If I see
>
> <map:transformers default="xslt"/>
>
> I know that this subsitemap expects 'xslt' to be defined for it. Why
> would I redefine it? If I wanted to, what's wrong with that?
>
There is nothing wrong with define another transformer, but it is wrong
if you are going to define the same transformer ( as it happends)
because that is duplication.
Belive or not, this code produces confusion, it you want to leave as
documentation then let's use <!-- coments -->. I do not like code that
does not anything but confuse :-)
>
> Yes I see that. For example, if we defined the HTML generator only in
> raw.xmap, and then later moved it to sitemap.xmap, we'd break things.
> However, we could always leave a duplicate definition in raw.xmap. The
> other way round (moving from sitemap.xmap to a subsitemap) always breaks
> things. It is still better to start with a limited scope, and then
> expand it if necessary.
>
The root problem is the way we overwrite sitemap, and the need for users
to overwrite it.
Can we have an external xml file with all definitions?
Cheers,
Cheche