You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gianugo Rabellino <gi...@apache.org> on 2003/10/24 16:49:50 UTC
[RT] Sitemap inheritance (was: User Pipeline Customization)
I'll take this lenya-dev post from Andreas as a starting point, since
this is a blatant case of "shared neurons": I was thinking about exactly
the same things this morning on a conversation with Ricardo, and the
more I think about it, the more I tend to realize that it would boost
Cocoon productivity even more.
> I could also imagine something like "sitemap inheritance".
> I guess in this case the inheriting sitemaps would have to
> be known at compile-time and the corresponding pipelines
> would have to be replaced. But I'm not aware of all the
> consequences of such a concept.
I have been quite uncomfortable at times with Cocoon management of large
applications. I was unable to realize exactly why I had some alarms off
scale, until a while ago, when I started thinking on how difficult is to
reuse sitemap logic across applications.
What happens to me quite often is that I'm constantly doing c&p from
sitemaps, trying to reuse existing snippets all over the place. This is
of course the poorest man's reuse technique, something I learnt should
be avoided at all costs.
So far, Cocoon has a few ways to "abstract" and "reuse" existing
pipelines: the "resource" concept and the cocoon protocol. Both,
however, are a bit clumsy and verbose. The resource bit has been so much
abused lately that the need for "virtual components" became pretty clear
(and indeed virtual components will be a huge help). The cocoon protocol
is somehow cleaner, but still requires long and error-prone copy & paste
operations.
Let's see a use case as an example, and take the simplest one, a
pipeline rendering xml, html or PDF depending on the URI extension,
included in the "simple.xmap" sitemap:
<pipeline>
<match pattern="*.xml">
<g type="file" src="{1}.xml/>
<s/>
</match>
<match pattern="*.html">
<g type="file" src="{1}.xml/>
<t src="xml2html.xsl"/>
<s type="html"/>
</match>
<match pattern="*.pdf">
<g type="file" src="{1}.xml/>
<t src="xml2fo.xsl"/>
<s type="fo2pdf"/>
</match>
</pipeline>
Suppose we have to build another Cocoon application, with a sitemap that
has to produce all the above outputs _plus_ excel files. If we had
sitemap inheritance (read: overriding) we could have just done:
<sitemap extends="simple.xmap">
[...]
<pipeline>
<!-- Newly added case -->
<match pattern="*.xls">
<g type="file" src="{1}.xml/>
<t src="xml2gnumeric.xsl"/>
<s type="poi"/>
</match>
</pipeline>
</sitemap>
The same goes for overriding. Suppose that the html transformation, in
this new pipeline, requires skinning. With overriding it would be as
simple as:
<sitemap extends="simple.xmap">
[...]
<pipeline>
<!-- Overridden HTML generation -->
<match pattern="*.html">
<g type="file" src="{1}.xml/>
<t src="xml2html.xsl"/>
<t src="skin.xsl"/>
<s type="poi"/>
</match>
</pipeline>
</sitemap>
Here, reuse would be promoted as its best, without a need for
resource-exists hacks and with a much cleaner, object oriented, sitemap
design in mind.
Of course all this opens an interesting can of worms:
1. unlike classes, pipeline ordering in the sitemap is important (so
it's not easy to decide where an added pipeline should go). This could
be a showstopper;
2. resource resolving can be messy: should source resolution be
performed in the parent sitemap (and context) or in the new one? Both
have pros and cons: as a generator parameter, it makes sense to resolve
it in the current context, but most probably the t-s are better served
if resolved in the parent's context.
3. URI matching might bring quite a few problems too.
The more I think about it, though, the more I feel that this solution
could be a usability boost for Cocoon. Probably hard to implement (even
if the components part already does inheritance), but still very useful
for complex Cocoon applications. And, in any case, even if _this_ is not
the solution, I think that we should provide a way to have
understandable and manageable sitemaps for complicated apps.
Does all this make any sense or is it just FS gibberish? :-)
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
(Note to dev@cocoon: Daniel's reply can be read at
http://article.gmane.org/gmane.comp.cms.lenya.devel/1496)
Daniel Fagerstrom wrote:
> Me to ;)
>
> I agree about all that you say and have also been through the process of
> hateing copy & paste style Cocoon app reuse, and foinding out that
> sitemap inheritance is the way to go.
>
> Still I think that the resource inheritance part of block inheritance is
> supposed to be build on some kind of sitemap inheritance, see e.g. the
> last part of
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106570773018093&w=2 and
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106577595921204&w=2
> "nono, inheritance works as the URI matching level, not at the resource
> level."
>
> I got that impression from Stefanos talk at the GT as well.
I might have missed that, but still I think that sitemap inheritance
does not belong to blocks but rather to the core.
> I think that the semantics of sitemap inheritance could be something
> like this:
>
> Say that sitemap2.xmap inherits from sitemap1.xmap, then I think that it
> should be interpreted as:
>
> sitemap2.xmap:
> <sitemap>
> <!-- diverse match clauses that will over ride or extend the inhereted
> ones -->
>
> <match pattern="**">
> <mount uri-prefix="" src="some-path/sitemap1.xmap"/>
> </match>
>
> <!-- error handling -->
> </sitemap>
>
> The idea is that everything that all URL:s that are not matched in
> sitemap2 will be tried in sitemap1. For error handling I think that
> sitemap2 should be able to "catch" errors from sitemap1 and resend them
> in a customized way, but I have no clear ideas about the details.
I'm sorry, but I don't like that too much. This should work now (or
pretty much work), but I don't like the match->delegate idea: it should
be transparent. Also, there can be ordering issues with side effects (no
figures yet, but still thinking). Ricardo has been suggesting to borrow
the xsl "include" and "import" concept (the latter allowing for
overrides): I think that this might be a better way.
>> Of course all this opens an interesting can of worms:
>>
>> 1. unlike classes, pipeline ordering in the sitemap is important (so
>> it's not easy to decide where an added pipeline should go). This could
>> be a showstopper;
>
>
> The inherited pipeline should IMO be used after everything in the
> extending pipeline. The main problem IMO is how the extending pipeline
> should handle errors in the inherited pipeline.
Let me think more about it. I do have a strong feeling that it won't
just be enough, I hope to come back soon with a few examples.
.
> I still think that this discussion is very relevant for Cocoon use in
> general and that we should discuss it at cocoon-dev.
This is why I cc'ed dev too, but you missed them in the reply. :-) This
time I changed the reply-to, so from now on it should end up on dev.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
(Note to dev@cocoon: Daniel's reply can be read at
http://article.gmane.org/gmane.comp.cms.lenya.devel/1496)
Daniel Fagerstrom wrote:
> Me to ;)
>
> I agree about all that you say and have also been through the process of
> hateing copy & paste style Cocoon app reuse, and foinding out that
> sitemap inheritance is the way to go.
>
> Still I think that the resource inheritance part of block inheritance is
> supposed to be build on some kind of sitemap inheritance, see e.g. the
> last part of
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106570773018093&w=2 and
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106577595921204&w=2
> "nono, inheritance works as the URI matching level, not at the resource
> level."
>
> I got that impression from Stefanos talk at the GT as well.
I might have missed that, but still I think that sitemap inheritance
does not belong to blocks but rather to the core.
> I think that the semantics of sitemap inheritance could be something
> like this:
>
> Say that sitemap2.xmap inherits from sitemap1.xmap, then I think that it
> should be interpreted as:
>
> sitemap2.xmap:
> <sitemap>
> <!-- diverse match clauses that will over ride or extend the inhereted
> ones -->
>
> <match pattern="**">
> <mount uri-prefix="" src="some-path/sitemap1.xmap"/>
> </match>
>
> <!-- error handling -->
> </sitemap>
>
> The idea is that everything that all URL:s that are not matched in
> sitemap2 will be tried in sitemap1. For error handling I think that
> sitemap2 should be able to "catch" errors from sitemap1 and resend them
> in a customized way, but I have no clear ideas about the details.
I'm sorry, but I don't like that too much. This should work now (or
pretty much work), but I don't like the match->delegate idea: it should
be transparent. Also, there can be ordering issues with side effects (no
figures yet, but still thinking). Ricardo has been suggesting to borrow
the xsl "include" and "import" concept (the latter allowing for
overrides): I think that this might be a better way.
>> Of course all this opens an interesting can of worms:
>>
>> 1. unlike classes, pipeline ordering in the sitemap is important (so
>> it's not easy to decide where an added pipeline should go). This could
>> be a showstopper;
>
>
> The inherited pipeline should IMO be used after everything in the
> extending pipeline. The main problem IMO is how the extending pipeline
> should handle errors in the inherited pipeline.
Let me think more about it. I do have a strong feeling that it won't
just be enough, I hope to come back soon with a few examples.
.
> I still think that this discussion is very relevant for Cocoon use in
> general and that we should discuss it at cocoon-dev.
This is why I cc'ed dev too, but you missed them in the reply. :-) This
time I changed the reply-to, so from now on it should end up on dev.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance (was: User Pipeline Customization)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Me to ;)
I agree about all that you say and have also been through the process of
hateing copy & paste style Cocoon app reuse, and foinding out that
sitemap inheritance is the way to go.
Still I think that the resource inheritance part of block inheritance is
supposed to be build on some kind of sitemap inheritance, see e.g. the
last part of
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106570773018093&w=2 and
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106577595921204&w=2
"nono, inheritance works as the URI matching level, not at the resource
level."
I got that impression from Stefanos talk at the GT as well.
Anyhow, I strongly believe that block inheritance should include sitemap
inheritance. I also think that sitemap inheritance is fairly orthogonal
to the rest of the block concepts and can be discussed separately.
I think that the semantics of sitemap inheritance could be something
like this:
Say that sitemap2.xmap inherits from sitemap1.xmap, then I think that it
should be interpreted as:
sitemap2.xmap:
<sitemap>
<!-- diverse match clauses that will over ride or extend the inhereted
ones -->
<match pattern="**">
<mount uri-prefix="" src="some-path/sitemap1.xmap"/>
</match>
<!-- error handling -->
</sitemap>
The idea is that everything that all URL:s that are not matched in
sitemap2 will be tried in sitemap1. For error handling I think that
sitemap2 should be able to "catch" errors from sitemap1 and resend them
in a customized way, but I have no clear ideas about the details.
Gianugo Rabellino wrote:
<snip/>
> Of course all this opens an interesting can of worms:
>
> 1. unlike classes, pipeline ordering in the sitemap is important (so
> it's not easy to decide where an added pipeline should go). This could
> be a showstopper;
The inherited pipeline should IMO be used after everything in the
extending pipeline. The main problem IMO is how the extending pipeline
should handle errors in the inherited pipeline.
> 2. resource resolving can be messy: should source resolution be
> performed in the parent sitemap (and context) or in the new one? Both
> have pros and cons: as a generator parameter, it makes sense to
> resolve it in the current context, but most probably the t-s are
> better served if resolved in the parent's context.
Here I think that cocoon: and file: are the only kind of resources that
depends on the context.
file:-resources should be considered as private local variables and
should be found wrt the current context. While the sitemap resources
i.e. those that you can get through the cocoon:-protocol should be
resolved in the context of the extending sitemap, booth for the
extending sitemap and the inherited one. This is necessary to get a
behaviour that corresponds to polymorphism in OO-languages.
I still think that this discussion is very relevant for Cocoon use in
general and that we should discuss it at cocoon-dev.
/Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Sitemap inheritance
Posted by Joerg Heinicke <jh...@virbus.de>.
On 25.10.2003 18:01, Gianugo Rabellino wrote:
> Giacomo Pati wrote:
>
>>> The more I think about it, though, the more I feel that this solution
>>> could be a usability boost for Cocoon. Probably hard to implement (even
>>> if the components part already does inheritance), but still very useful
>>> for complex Cocoon applications. And, in any case, even if _this_ is not
>>> the solution, I think that we should provide a way to have
>>> understandable and manageable sitemaps for complicated apps.
>>
>>
>> I'd rather see a solution similar to component inheritance because there
>> we have a clear anchor point to do inheritance. The pipeline inheritance
>> you've expressed would indeed be hard to implement as it is inheriting
>> at the matcher level which is already a final element in the sitemap
>> DTD. So why don't we think about inheriting hole pipelines similar to
>> components?
>
>
> Yes, it absolutely makes sense. The only problem I see is name
> collision: how do you handle the case when a user creates another
> pipeline with the same name? This shouldn't be permitted, and an
> (understandable) error should be fired. Apart from this, I'm perfectly
> fine and I think it makes sense.
>
> How about ordering? Should new matchers be appended to the extended ones
> and overriden matchers be substituted? Is that OK to everyone?
Isn't it a simple fallback to the extended sitemap after all matchers in
the extending pipeline have been tested?
Joerg
Re: [RT] Sitemap inheritance
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 21:22 Europe/Rome, Gianugo Rabellino wrote:
> If this means "shielding" users from the need of having a block, I
> completely rest my case. But we need to have backward compatibility to
> what we have now: unpack war (or go to build/webapp) and work from
> there. Anything more complicated, no matter what the advantages are,
> would just be overkill to the average user.
Let me start saying that 'usability of the system during development'
is a top priority and must work with blocks as well. The use of a
blockpath is an idea, but there could be others on the table.
Anyway, the concern of "make it simple for developers" is (and has
always been) a top priority for me. This is a different concern in
whether we want inheritance to happen at the sitemap level or at the
block level.
Sylvain and I say that it should be at the block level, you say it
should be at the sitemap level.
Note: the above does *NOT* have anything to do with regular WAR-style
deployment. Once blocks are deployed, you can repack everything in a
war file and use that. so blocks or sitemap nothing changes.
there are two big advantages in block-level that are missed at sitemap
level:
1) transparent versioning
2) solid isolation
Everybody knows that composition should be favored over inheritance.
Make it *easy* for people to abuse something, and they will. massively.
actions, resources, and now inheritance. I fear abuse.
Blocks are an obstacle, yes, but a little one and one that forces
people to think.
I know you can't force people to think. but if you are a cocoon user
you are used to be guided a little bit. perl users, for example,
wouldn't like cocoon because it's too rigid.
I don't want to make it any more rigid, but I don't want to make it any
more loose either, this is why inheritance should go along with a
compositional design, not otherwise.
but I understand this is a subjective thing, so, we might want to hear
other bells on this.
--
Stefano.
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
> Gianugo Rabellino wrote:
>
>> Sylvain Wallez wrote:
>>
รน>>>> To me, having inheritance only in blocks look a bit like saying that
>>>> you can extend only from java.*, while user classes have to be
>>>> always final. It's rough and inaccurate, but can you see my point?
>>>
>>>
>>>
>>> Mmmh... by "java.*", I understand that you consider that only the
>>> Cocoon team will define block interfaces. But everybody can define
>>> its own private block interface and its implementations and do
>>> whatever it wants with it. This only requires to have a local block
>>> librarian for those private blocks that is queried before the main
>>> Cocoon librarian. This is similar to setting up a classpath that will
>>> add your own classes to those in the JRE.
>>
>>
>>
>> Fair enough: I will be able to provide my own block, and so will you
>> and possibly everyone who reads this mail. But the problem is that
>> only people with "block librarian" skills will be able to use Cocoon,
>> if everything is packaged as a block. I'm afraid that this would just
>> scare people away, even before they can understand the huge benefit of
>> blocks.
>
>
>
> Sorry Gianugo, I meant no offense, and I see your point now.
No problem, I didn't see or take any offense in your reply. :-)
> The concern
> is actually about the ease of use of what we can call "local blocks".
>
> I had talks with Stefano about the need to have blocks non-archive
> blocks on the local filesystem for roundtrip time during development
> (you don't want to build a cob file to test each time you change a
> line).
Yes, definitely you don't.
> We can extend this behaviour to local blocks that allow
> "non-librarian-aware" people to use the blocks mechanisms without having
> to run a librarian server, package their blocks and all the associated
> stuff.
>
> Implementation-wise, this may mean that the block deployer can rely not
> only on a remote librarian server, but also on a local "blockpath" that
> is queried first before the remote server.
If this means "shielding" users from the need of having a block, I
completely rest my case. But we need to have backward compatibility to
what we have now: unpack war (or go to build/webapp) and work from
there. Anything more complicated, no matter what the advantages are,
would just be overkill to the average user.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
...
> The concern
> is actually about the ease of use of what we can call "local blocks".
>
> I had talks with Stefano about the need to have blocks non-archive
> blocks on the local filesystem for roundtrip time during development
> (you don't want to build a cob file to test each time you change a
> line). We can extend this behaviour to local blocks that allow
> "non-librarian-aware" people to use the blocks mechanisms without having
> to run a librarian server, package their blocks and all the associated
> stuff.
>
> Implementation-wise, this may mean that the block deployer can rely not
> only on a remote librarian server, but also on a local "blockpath" that
> is queried first before the remote server.
Since this discussion started about a use-case, here it is:
Forrest has some standard sitemaps that are mounted in the main sitemap.
I can imagine that in the future each of these would be a block.
Now we enable users to change the sitemap and use their versions
instead, by overcopying the standard version with their own. It would be
nice if they could delegate back to the standard version if they don't
have a match hit, so that they can just decorate it with their changes
(and not have to copy in all the "standard" parts).
This needs some sort of inheritance. But if these sitemaps are blocks,
then this would seem to be ok...
I don't have the real big fat itch of making inheritance now as long as
blocks have it. When they will come, I'll do an assessment, and we'll
see if the issues are still there.
In any case I'll hang around to see how things are proceeding, and help
from a users's POV.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Sitemap inheritance
Posted by Sylvain Wallez <sy...@apache.org>.
Gianugo Rabellino wrote:
> Sylvain Wallez wrote:
>
>>>
>>> To me, having inheritance only in blocks look a bit like saying that
>>> you can extend only from java.*, while user classes have to be
>>> always final. It's rough and inaccurate, but can you see my point?
>>
>>
>> Mmmh... by "java.*", I understand that you consider that only the
>> Cocoon team will define block interfaces. But everybody can define
>> its own private block interface and its implementations and do
>> whatever it wants with it. This only requires to have a local block
>> librarian for those private blocks that is queried before the main
>> Cocoon librarian. This is similar to setting up a classpath that will
>> add your own classes to those in the JRE.
>
>
> Fair enough: I will be able to provide my own block, and so will you
> and possibly everyone who reads this mail. But the problem is that
> only people with "block librarian" skills will be able to use Cocoon,
> if everything is packaged as a block. I'm afraid that this would just
> scare people away, even before they can understand the huge benefit of
> blocks.
Sorry Gianugo, I meant no offense, and I see your point now. The concern
is actually about the ease of use of what we can call "local blocks".
I had talks with Stefano about the need to have blocks non-archive
blocks on the local filesystem for roundtrip time during development
(you don't want to build a cob file to test each time you change a
line). We can extend this behaviour to local blocks that allow
"non-librarian-aware" people to use the blocks mechanisms without having
to run a librarian server, package their blocks and all the associated
stuff.
Implementation-wise, this may mean that the block deployer can rely not
only on a remote librarian server, but also on a local "blockpath" that
is queried first before the remote server.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
>>
>> To me, having inheritance only in blocks look a bit like saying that
>> you can extend only from java.*, while user classes have to be always
>> final. It's rough and inaccurate, but can you see my point?
>
>
>
> Mmmh... by "java.*", I understand that you consider that only the Cocoon
> team will define block interfaces. But everybody can define its own
> private block interface and its implementations and do whatever it wants
> with it. This only requires to have a local block librarian for those
> private blocks that is queried before the main Cocoon librarian. This is
> similar to setting up a classpath that will add your own classes to
> those in the JRE.
Fair enough: I will be able to provide my own block, and so will you and
possibly everyone who reads this mail. But the problem is that only
people with "block librarian" skills will be able to use Cocoon, if
everything is packaged as a block. I'm afraid that this would just scare
people away, even before they can understand the huge benefit of blocks.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance
Posted by Sylvain Wallez <sy...@apache.org>.
Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>
>> On Saturday, Oct 25, 2003, at 18:01 Europe/Rome, Gianugo Rabellino
>> wrote:
>>
>>> Is that OK to everyone?
>>
>>
>> No. I still have to understand what's wrong with the sitemap
>> inheritance that blocks introduce.
>
>
> Probably I should be more aware of what kind of inheritance exactly
> block introduce in your design. So far I haven't been able to find
> anything explicitly oriented to pipeline reuse/inheritance: it's
> pretty clear that components (classes) will be inherited, and the same
> goes for resources, but what about pipelines? I'm not *that* sure that
> it makes actually sense to inherit them by default.
>
> But then again, I don't think that blocks will be enough, if blocks
> are to be the only way to have inheritance. The final user won't
> package every single application as a block, and even inside the sime
> application she/he might find himself with more than one sitemap, not
> being able to reuse preexisting logic.
>
> To me, having inheritance only in blocks look a bit like saying that
> you can extend only from java.*, while user classes have to be always
> final. It's rough and inaccurate, but can you see my point?
Mmmh... by "java.*", I understand that you consider that only the Cocoon
team will define block interfaces. But everybody can define its own
private block interface and its implementations and do whatever it wants
with it. This only requires to have a local block librarian for those
private blocks that is queried before the main Cocoon librarian. This is
similar to setting up a classpath that will add your own classes to
those in the JRE.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Sitemap inheritance
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 23:51 Europe/Rome, Gianugo Rabellino wrote:
> Geoff Howard wrote:
>> Gianugo Rabellino wrote:
>
>>> In short: blocks should ease a Cocoon developer's life, and block
>>> assembling should belong to the "programmer" domain. Normal users
>>> should see only benefits from it. Or am I wrong?
>> I believe that the benefits from real blocks will be so monumental to
>> the way people work with Cocoon that every application should be
>> packaged as a block/group of blocks. Much of the pain of developing
>> with Cocoon (more than the first little tinkering) goes away. We
>> need to make sure blocks are not scary to people, but I don't think
>> this is going to be difficult. I'd propose waiting until we have a
>> first working draft before further investigating alternatives which
>> replace blocks.
>
> Just to make things clear: I'm not advocating an alternative to
> replace blocks, I'm a strong fan of it. I just think that blocks
> should ease development of Cocoon apps, while not becoming the only
> way of working with Cocoon. In the upcoming future I see lots of
> blocks being interconnected by traditional sitemap editing as we're
> used to it now.
>
> Sitemap (better: pipeline) inheritance goes in this direction: it's
> perfectly OK and cool to have it within blocks, but I don't see why it
> should not be possible even outside them. So I'm not stating anything
> that goes against blocks: I'm just looking for a way to ease the final
> user experience with Cocoon. Keeping in mind that the majority of
> users won't make blocks, but rather just use them.
I'm sorry, but this seems to me like stating that even if the java
libraries are well object oriented, we have to make sure that people
can write C-like code with them and make it easier for them to do so.
As java go *exactly* the other way (make life easier for people that
follow OO patterns), and it's one of the reason why I like java and the
community around it (I dislike when they get to religious about it, but
that's another story)
why shouldn't we do the same?
I know it's impossible for a system to "teach" people how to program,
but for sure I can make their life a little harder if they are going in
the direction that this community is not following: this will force
them to look around for better and easier ways and we'll make sure to
make their life easier if they follow our practices.
I suggest we make it easier for people to write blocks, not give them
shortcuts to go around them and consider them obstacles.
--
Stefano.
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
Geoff Howard wrote:
> Gianugo Rabellino wrote:
>
>> In short: blocks should ease a Cocoon developer's life, and block
>> assembling should belong to the "programmer" domain. Normal users
>> should see only benefits from it. Or am I wrong?
>
>
>
> I believe that the benefits from real blocks will be so monumental to
> the way people work with Cocoon that every application should be
> packaged as a block/group of blocks. Much of the pain of developing
> with Cocoon (more than the first little tinkering) goes away. We need
> to make sure blocks are not scary to people, but I don't think this is
> going to be difficult. I'd propose waiting until we have a first
> working draft before further investigating alternatives which replace
> blocks.
Just to make things clear: I'm not advocating an alternative to replace
blocks, I'm a strong fan of it. I just think that blocks should ease
development of Cocoon apps, while not becoming the only way of working
with Cocoon. In the upcoming future I see lots of blocks being
interconnected by traditional sitemap editing as we're used to it now.
Sitemap (better: pipeline) inheritance goes in this direction: it's
perfectly OK and cool to have it within blocks, but I don't see why it
should not be possible even outside them. So I'm not stating anything
that goes against blocks: I'm just looking for a way to ease the final
user experience with Cocoon. Keeping in mind that the majority of users
won't make blocks, but rather just use them.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance
Posted by Geoff Howard <co...@leverageweb.com>.
Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>
>>> Probably I should be more aware of what kind of inheritance exactly
>>> block introduce in your design.
>>
>> I might be wrong, but I think that the current block inheritance
>> mechanism does exactly what you were describing in your previous emails.
>>
>>> So far I haven't been able to find anything explicitly oriented to
>>> pipeline reuse/inheritance: it's pretty clear that components
>>> (classes) will be inherited, and the same goes for resources, but
>>> what about pipelines?
>>
>>
>> I'm not sure we are using the same terminology here. but let me give
>> you an example of how the blocks will work:
>
>
> [...]
>
> As long as there is room for overriding, i.e.:
>
> block a
>
> ...
> <pipeline>
> <match pattern="*.html">
> ... do something ...
> </match>
> </pipeline>
> ...
>
> block b extends block a
>
> ...
> <pipeline>
> <match pattern="*.html">
> ... do something different ...
> </match>
> </pipeline>
> ...
>
> I'm fine with it. *But*, again, this is a block-only behaviour (works
> as long as you have two blocks).
>
>
>>> To me, having inheritance only in blocks look a bit like saying that
>>> you can extend only from java.*, while user classes have to be
>>> always final. It's rough and inaccurate, but can you see my point?
>>
>>
>>
>> hmmm, not really. blocks are application level components that
>> isolate your logic. this is exactly what you are going to need. it
>> would be like saying that object orientation is overkill for
>> datatypes and nothing is wrong with C unions.
>>
>> I do agree that it looks like overkill to come up with a block for
>> your own stuff that you need to inherit, but i think that this will
>> force you to define contracts betweeen stuff and this will help you
>> later on (just like OOP datatypes vs. unions)
>>
>> but, supposing for a second we allow sitemap inheritance without
>> blocks, how would you make it work for both?
>
>
> I guess that once you have pipeline inheritance, it would be easy
> enough to have it working both on blocks and on "ordinary" user
> configurations. But my strongest point is that Cocoon has a steep
> learning curve already, and while I do foresee some benefits in having
> *everything* packaged as a block, I still think that there should be
> room for traditional (=sitemap on filesystem) Cocoon development.
>
> This is also good for development: if the cycle becomes "edit
> sitemap->package as block->install in cocoon->fail->retry" I guess it
> would just be too heavy for users.
>
> Keep in mind that we should account for non-Java savy users too,
> people who might be uncomfortable in using jar techniques, edit
> metafiles, running ant and so on. Today all that is required to run
> Cocoon is XML knowledge and a text editor: if everything becomes a
> block, Cocoon will remain just a Java-developer-centric application.
>
> In short: blocks should ease a Cocoon developer's life, and block
> assembling should belong to the "programmer" domain. Normal users
> should see only benefits from it. Or am I wrong?
I believe that the benefits from real blocks will be so monumental to
the way people work with Cocoon that every application should be
packaged as a block/group of blocks. Much of the pain of developing
with Cocoon (more than the first little tinkering) goes away. We need
to make sure blocks are not scary to people, but I don't think this is
going to be difficult. I'd propose waiting until we have a first
working draft before further investigating alternatives which replace
blocks.
Geoff
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>> Probably I should be more aware of what kind of inheritance exactly
>> block introduce in your design.
> I might be wrong, but I think that the current block inheritance
> mechanism does exactly what you were describing in your previous emails.
>
>> So far I haven't been able to find anything explicitly oriented to
>> pipeline reuse/inheritance: it's pretty clear that components
>> (classes) will be inherited, and the same goes for resources, but what
>> about pipelines?
>
> I'm not sure we are using the same terminology here. but let me give you
> an example of how the blocks will work:
[...]
As long as there is room for overriding, i.e.:
block a
...
<pipeline>
<match pattern="*.html">
... do something ...
</match>
</pipeline>
...
block b extends block a
...
<pipeline>
<match pattern="*.html">
... do something different ...
</match>
</pipeline>
...
I'm fine with it. *But*, again, this is a block-only behaviour (works as
long as you have two blocks).
>> To me, having inheritance only in blocks look a bit like saying that
>> you can extend only from java.*, while user classes have to be always
>> final. It's rough and inaccurate, but can you see my point?
>
>
> hmmm, not really. blocks are application level components that isolate
> your logic. this is exactly what you are going to need. it would be like
> saying that object orientation is overkill for datatypes and nothing is
> wrong with C unions.
>
> I do agree that it looks like overkill to come up with a block for your
> own stuff that you need to inherit, but i think that this will force you
> to define contracts betweeen stuff and this will help you later on (just
> like OOP datatypes vs. unions)
>
> but, supposing for a second we allow sitemap inheritance without blocks,
> how would you make it work for both?
I guess that once you have pipeline inheritance, it would be easy enough
to have it working both on blocks and on "ordinary" user configurations.
But my strongest point is that Cocoon has a steep learning curve
already, and while I do foresee some benefits in having *everything*
packaged as a block, I still think that there should be room for
traditional (=sitemap on filesystem) Cocoon development.
This is also good for development: if the cycle becomes "edit
sitemap->package as block->install in cocoon->fail->retry" I guess it
would just be too heavy for users.
Keep in mind that we should account for non-Java savy users too, people
who might be uncomfortable in using jar techniques, edit metafiles,
running ant and so on. Today all that is required to run Cocoon is XML
knowledge and a text editor: if everything becomes a block, Cocoon will
remain just a Java-developer-centric application.
In short: blocks should ease a Cocoon developer's life, and block
assembling should belong to the "programmer" domain. Normal users should
see only benefits from it. Or am I wrong?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 26, 2003, at 11:16 Europe/Rome, Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>> On Saturday, Oct 25, 2003, at 18:01 Europe/Rome, Gianugo Rabellino
>> wrote:
>>> Is that OK to everyone?
>> No. I still have to understand what's wrong with the sitemap
>> inheritance that blocks introduce.
>
> Probably I should be more aware of what kind of inheritance exactly
> block introduce in your design.
I might be wrong, but I think that the current block inheritance
mechanism does exactly what you were describing in your previous emails.
> So far I haven't been able to find anything explicitly oriented to
> pipeline reuse/inheritance: it's pretty clear that components
> (classes) will be inherited, and the same goes for resources, but what
> about pipelines?
I'm not sure we are using the same terminology here. but let me give
you an example of how the blocks will work:
block a
...
<pipeline>
<match pattern="*.html">
... do something ...
</match>
</pipeline>
...
block b
...
<pipeline>
<match pattern="ciao.html">
... do something different ...
</match>
</pipeline>
...
cases:
1) block a is mounted on /
asking for "/ciao.html" will give you the "do something" pipeline
asking for "/whatever.html" will give you the same pipeline
2) block b is mounted on /
asking for "/ciao.html" will give you the "do something different"
pipeline
asking for "/whatever.html" will give you 404
3) block b extends block a and is mounted on /
asking for "/ciao.html" will give you the "do something different"
pipeline
asking for "/whatever.html" will give you the "do something"
pipeline
> I'm not *that* sure that it makes actually sense to inherit them by
> default.
It's not by default, it's up to you to choose if your block inherits or
not (as above)
> But then again, I don't think that blocks will be enough, if blocks
> are to be the only way to have inheritance. The final user won't
> package every single application as a block, and even inside the sime
> application she/he might find himself with more than one sitemap, not
> being able to reuse preexisting logic.
>
> To me, having inheritance only in blocks look a bit like saying that
> you can extend only from java.*, while user classes have to be always
> final. It's rough and inaccurate, but can you see my point?
hmmm, not really. blocks are application level components that isolate
your logic. this is exactly what you are going to need. it would be
like saying that object orientation is overkill for datatypes and
nothing is wrong with C unions.
I do agree that it looks like overkill to come up with a block for your
own stuff that you need to inherit, but i think that this will force
you to define contracts betweeen stuff and this will help you later on
(just like OOP datatypes vs. unions)
but, supposing for a second we allow sitemap inheritance without
blocks, how would you make it work for both?
--
Stefano.
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Saturday, Oct 25, 2003, at 18:01 Europe/Rome, Gianugo Rabellino wrote:
>
>> Is that OK to everyone?
>
>
>
> No. I still have to understand what's wrong with the sitemap inheritance
> that blocks introduce.
Probably I should be more aware of what kind of inheritance exactly
block introduce in your design. So far I haven't been able to find
anything explicitly oriented to pipeline reuse/inheritance: it's pretty
clear that components (classes) will be inherited, and the same goes for
resources, but what about pipelines? I'm not *that* sure that it makes
actually sense to inherit them by default.
But then again, I don't think that blocks will be enough, if blocks are
to be the only way to have inheritance. The final user won't package
every single application as a block, and even inside the sime
application she/he might find himself with more than one sitemap, not
being able to reuse preexisting logic.
To me, having inheritance only in blocks look a bit like saying that you
can extend only from java.*, while user classes have to be always final.
It's rough and inaccurate, but can you see my point?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Oct 25, 2003, at 18:01 Europe/Rome, Gianugo Rabellino
wrote:
> Is that OK to everyone?
No. I still have to understand what's wrong with the sitemap
inheritance that blocks introduce.
--
Stefano.
Re: [RT] Sitemap inheritance
Posted by Gianugo Rabellino <gi...@apache.org>.
Giacomo Pati wrote:
> On Fri, 24 Oct 2003, Gianugo Rabellino wrote:
>
> <snipped/>
>
>>The more I think about it, though, the more I feel that this solution
>>could be a usability boost for Cocoon. Probably hard to implement (even
>>if the components part already does inheritance), but still very useful
>>for complex Cocoon applications. And, in any case, even if _this_ is not
>>the solution, I think that we should provide a way to have
>>understandable and manageable sitemaps for complicated apps.
>
>
> I'd rather see a solution similar to component inheritance because there
> we have a clear anchor point to do inheritance. The pipeline inheritance
> you've expressed would indeed be hard to implement as it is inheriting
> at the matcher level which is already a final element in the sitemap
> DTD. So why don't we think about inheriting hole pipelines similar to
> components?
Yes, it absolutely makes sense. The only problem I see is name
collision: how do you handle the case when a user creates another
pipeline with the same name? This shouldn't be permitted, and an
(understandable) error should be fired. Apart from this, I'm perfectly
fine and I think it makes sense.
How about ordering? Should new matchers be appended to the extended ones
and overriden matchers be substituted? Is that OK to everyone?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Sitemap inheritance (was: User Pipeline Customization)
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 24 Oct 2003, Gianugo Rabellino wrote:
<snipped/>
> The more I think about it, though, the more I feel that this solution
> could be a usability boost for Cocoon. Probably hard to implement (even
> if the components part already does inheritance), but still very useful
> for complex Cocoon applications. And, in any case, even if _this_ is not
> the solution, I think that we should provide a way to have
> understandable and manageable sitemaps for complicated apps.
I'd rather see a solution similar to component inheritance because there
we have a clear anchor point to do inheritance. The pipeline inheritance
you've expressed would indeed be hard to implement as it is inheriting
at the matcher level which is already a final element in the sitemap
DTD. So why don't we think about inheriting hole pipelines similar to
components? As an example:
<pipeline>
<match pattern="*.xml">
<g type="file" src="{1}.xml/>
<s/>
</match>
<match pattern="*.html">
<g type="file" src="{1}.xml/>
<t src="xml2html.xsl"/>
<s type="html"/>
</match>
<match pattern="*.pdf">
<g type="file" src="{1}.xml/>
<t src="xml2fo.xsl"/>
<s type="fo2pdf"/>
</match>
</pipeline>
This is your propose sample pipeline and this
<sitemap extends="simple.xmap">
[...]
<pipeline>
<!-- Newly added case -->
<match pattern="*.xls">
<g type="file" src="{1}.xml/>
<t src="xml2gnumeric.xsl"/>
<s type="poi"/>
</match>
</pipeline>
</sitemap>
is your inherited one. I'd like to propose doing it like this:
<pipeline name="master">
<match pattern="*.xml">
<g type="file" src="{1}.xml/>
<s/>
</match>
<match pattern="*.html">
<g type="file" src="{1}.xml/>
<t src="xml2html.xsl"/>
<s type="html"/>
</match>
<match pattern="*.pdf">
<g type="file" src="{1}.xml/>
<t src="xml2fo.xsl"/>
<s type="fo2pdf"/>
</match>
</pipeline>
and
<sitemap>
[...]
<pipeline extends="master">
<!-- Newly added case -->
<match pattern="*.xls">
<g type="file" src="{1}.xml/>
<t src="xml2gnumeric.xsl"/>
<s type="poi"/>
</match>
</pipeline>
</sitemap>
I think is would be much easier to implement because pipelines cannot be
nested but matcher do (often). I feel it would be hard (performance
wise) to compare matchers of the same type and with the same pattern up
the tree (I know you are not proposing tree inheritance but simply
extending a template sitemap file)
What do you think about this?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Sitemap inheritance (was: User Pipeline Customization)
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 24 Oct 2003, Gianugo Rabellino wrote:
<snipped/>
> The more I think about it, though, the more I feel that this solution
> could be a usability boost for Cocoon. Probably hard to implement (even
> if the components part already does inheritance), but still very useful
> for complex Cocoon applications. And, in any case, even if _this_ is not
> the solution, I think that we should provide a way to have
> understandable and manageable sitemaps for complicated apps.
I'd rather see a solution similar to component inheritance because there
we have a clear anchor point to do inheritance. The pipeline inheritance
you've expressed would indeed be hard to implement as it is inheriting
at the matcher level which is already a final element in the sitemap
DTD. So why don't we think about inheriting hole pipelines similar to
components? As an example:
<pipeline>
<match pattern="*.xml">
<g type="file" src="{1}.xml/>
<s/>
</match>
<match pattern="*.html">
<g type="file" src="{1}.xml/>
<t src="xml2html.xsl"/>
<s type="html"/>
</match>
<match pattern="*.pdf">
<g type="file" src="{1}.xml/>
<t src="xml2fo.xsl"/>
<s type="fo2pdf"/>
</match>
</pipeline>
This is your propose sample pipeline and this
<sitemap extends="simple.xmap">
[...]
<pipeline>
<!-- Newly added case -->
<match pattern="*.xls">
<g type="file" src="{1}.xml/>
<t src="xml2gnumeric.xsl"/>
<s type="poi"/>
</match>
</pipeline>
</sitemap>
is your inherited one. I'd like to propose doing it like this:
<pipeline name="master">
<match pattern="*.xml">
<g type="file" src="{1}.xml/>
<s/>
</match>
<match pattern="*.html">
<g type="file" src="{1}.xml/>
<t src="xml2html.xsl"/>
<s type="html"/>
</match>
<match pattern="*.pdf">
<g type="file" src="{1}.xml/>
<t src="xml2fo.xsl"/>
<s type="fo2pdf"/>
</match>
</pipeline>
and
<sitemap>
[...]
<pipeline extends="master">
<!-- Newly added case -->
<match pattern="*.xls">
<g type="file" src="{1}.xml/>
<t src="xml2gnumeric.xsl"/>
<s type="poi"/>
</match>
</pipeline>
</sitemap>
I think is would be much easier to implement because pipelines cannot be
nested but matcher do (often). I feel it would be hard (performance
wise) to compare matchers of the same type and with the same pattern up
the tree (I know you are not proposing tree inheritance but simply
extending a template sitemap file)
What do you think about this?
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com