Re: [C3] redirect-to/@uri optional?
Reinhard Pötz pisze: So do you agree with me changing both schema and implementation so @uri is required? yes, go ahead Done in r753635. The same concern (about too many of optional attributes) applies to call instruction. What about this? @controller and @select could be mandatory. Once I was thinking about having a default controller for a sitemap (e.g. defined at the root element) but have never implemented it. It that case @controller would have to become optional. I've made them required in r753634. Right. I wasn't active committer at that time so I can't remember original goals of TreeProcessor. Anyway, I wonder if this functionality was ever used in 2.x? I can't recall such a situation. If I understand it correctly having extensible sitemap language adds quite a lot to complexity of sitemap implementation. I would like to know what kind of issues extensibility of sitemap language solves. There was the idea of designing page flows in XML (very similar to Spring MVC) but this idea was dropped in favor of Flowscript. You can guess now how old this idea has to be ;-) Nowadays I don't know of any use case but when we implemented cocoon-sitemap we thought that we should make it extensible, especially because the sitemap module can be used stand-alone very easily. I see. Thanks for explaining it to me. I do not fully agree with the point that sitemap should be extensible but we'll discuss this in Amsterdam. At least I hope so. -- Best regards, Grzegorz Kossakowski
Re: [C3] redirect-to/@uri optional?
Reinhard Pötz pisze: Grzegorz Kossakowski wrote: Hi, It's again me trying to understand current sitemap design. This time I wonder if it's intended that redirect-to/@uri is optional. I fail to see how implementation of redirect-to handles this case in any meaningful way. I haven't tried it now what happens if the there is no @uri attribute but from reading the code some exception in the RedirectorComponent will occur. It's probably better to throw a meaningful exception in the RedirectorNode. So do you agree with me changing both schema and implementation so @uri is required? The same concern (about too many of optional attributes) applies to call instruction. What about this? BTW. Was the idea of having extensible sitemap syntax discussed earlier? As it something new I wonder what was the main idea behind such a design decision. Why do you think that this is new? When Sylvain wrote the TreeProcessor, one of his main goals was extensibility. Right. I wasn't active committer at that time so I can't remember original goals of TreeProcessor. Anyway, I wonder if this functionality was ever used in 2.x? I can't recall such a situation. If I understand it correctly having extensible sitemap language adds quite a lot to complexity of sitemap implementation. I would like to know what kind of issues extensibility of sitemap language solves. -- Best regards, Grzegorz Kossakowski
Re: [C3] redirect-to/@uri optional?
Grzegorz Kossakowski wrote:
Reinhard Pötz pisze:
Grzegorz Kossakowski wrote:
Hi,
It's again me trying to understand current sitemap design. This time
I wonder if it's intended that redirect-to/@uri is optional. I fail
to see how implementation of redirect-to handles this case in any
meaningful way.
I haven't tried it now what happens if the there is no @uri attribute
but from reading the code some exception in the RedirectorComponent will
occur. It's probably better to throw a meaningful exception in the
RedirectorNode.
So do you agree with me changing both schema and implementation so @uri is
required?
yes, go ahead
llnode
The same concern (about too many of optional attributes) applies to
call instruction.
What about this?
@controller and @select could be mandatory. Once I was thinking about
having a default controller for a sitemap (e.g. defined at the root
element) but have never implemented it. It that case @controller would
have to become optional.
BTW. Was the idea of having extensible sitemap syntax discussed
earlier? As it something new I wonder what was the main idea behind
such a design decision.
Why do you think that this is new? When Sylvain wrote the TreeProcessor,
one of his main goals was extensibility.
Right. I wasn't active committer at that time so I can't remember original
goals of TreeProcessor. Anyway, I wonder if
this functionality was ever used in 2.x? I can't recall such a situation.
If I understand it correctly having extensible sitemap language adds quite a
lot to complexity of sitemap
implementation. I would like to know what kind of issues extensibility of
sitemap language solves.
There was the idea of designing page flows in XML (very similar to
Spring MVC) but this idea was dropped in favor of Flowscript. You can
guess now how old this idea has to be ;-)
Nowadays I don't know of any use case but when we implemented
cocoon-sitemap we thought that we should make it extensible, especially
because the sitemap module can be used stand-alone very easily.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
[C3] redirect-to/@uri optional?
Hi, It's again me trying to understand current sitemap design. This time I wonder if it's intended that redirect-to/@uri is optional. I fail to see how implementation of redirect-to handles this case in any meaningful way. The same concern (about too many of optional attributes) applies to call instruction. BTW. Was the idea of having extensible sitemap syntax discussed earlier? As it something new I wonder what was the main idea behind such a design decision. Thanks for you patient answers. -- Best regards, Grzegorz Kossakowski
Re: [C3] redirect-to/@uri optional?
Grzegorz Kossakowski wrote:
Hi,
It's again me trying to understand current sitemap design. This time
I wonder if it's intended that redirect-to/@uri is optional. I fail
to see how implementation of redirect-to handles this case in any
meaningful way.
I haven't tried it now what happens if the there is no @uri attribute
but from reading the code some exception in the RedirectorComponent will
occur. It's probably better to throw a meaningful exception in the
RedirectorNode.
The same concern (about too many of optional attributes) applies to
call instruction.
BTW. Was the idea of having extensible sitemap syntax discussed
earlier? As it something new I wonder what was the main idea behind
such a design decision.
Why do you think that this is new? When Sylvain wrote the TreeProcessor,
one of his main goals was extensibility.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
