On 7 Nov 2003, at 17:22, Guido Casper wrote:
Stefano Mazzocchi wrote:On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote:
I agree with comments in this other thread that let's not introduce nested components in <map:call/>. Instead, if needed, let's introduce <act type="flow"/>. Sometime later.
-1
Your -1 means: "replace later with never", right? Just to remove any possible point of confusion :)
yes. I am against the silly
<xxx> ... do something if true </xx> .. do something if false
syntax. doesn't matter what the logic that drives the "xxx" tag is or what "xxx" is remapped to.
Wow, that would rule out matchers as well.
But it might make some sense since matchers are not all that different to
actions ;-)
Careful. I'm against the use of
<match src="something"> </match> <read/>
as well. The proper way should be
<match src="something"> ... </match>
<match src="**"> <reader/> </match>
having the logic processing not following the element nesting, is, IMO, very confusing and very bad practice.
In the original sitemap design, it was *NOT* possible to have pipeline components inside <pipeline>, only matchers. This is something that was introduced while I wasn't watching, just like actions.
Yes, actions are not the only the only things I dislike about the sitemap: the tree processor introduced new ways of dealing with things (like having resources without generators or serializers, or pipeline components in pipelines without matchers)... but all these things ended up being more harm than good from a usage perspective.
So, what's the point of introducing something and then come out with "best practices" that prevent you from using them?
-- Stefano.
