Max Larsson wrote:
>Hi,
>
>what you want to do wokrs in this way.
>
>
><map:match ...>
> <map:act ...>
> ...on success
> <map:serialze/>
> </map:act>
> ... the following is only executed on failure
> <map:generate/>
> <map:serialze/>
></map:match>
>
>
>An action fails if it returns null in his act method.
>And i think it is important to have a serilizer or
>reader within the action else it wouldn't stop. It would
>than continue after the action.
>
>HTH
>
>Max
>
And then...
>
>Bryan, there's another way to communicate with the rest which is
>request attributes. So set such a beast in your action containing the
>results and have your other components act accordingly. If you need to
>change the pipeline it would mean to use a selector that works on
>request attributes. There's one supplied with Cocoon.
>
> Chris.
>
You both make valid points, and I don't disagree with you. I do know
there are better ways to approach this problem (as I said in my original
email). But I guess my concern is this... The sitemap pipeline is
essentially a mini-programming language. The problem with it being a
mini-programming language is people start to expect things (things like
looping constructs, case statements, if statments, consistent behavior,
and the like). Implementing a language that works as everybody expects
is an extremely difficult thing to do.
Here's my perspective. First, we'll start out with a sample sitemap
entry, which I think is about as simpel as you can get:
<match pattern=".*">
<generate/>
<act name="something">
<act-failure>
<transform name="insert-errors"/>
</act-failure>
</act>
<serialize/>
</match>
vs which is more or less equivalent:
<match pattern=".*">
<generate>
<act name="something">
<serialize/>
</act>
<transform name="insert-errors"/>
<serialize/>
</match>
For perspective, I am working on a framework implemented in Ruby that
does essentially the same things Cocoon does. Personally, I'm a VERY
big fan of Cocoon, but not a big fan of Java, so creating a framework in
Ruby seemd a very natural thing to do.
As I was implementing actions in the pipeline I got to thinking about
all the possible ways I would use them. One way that seemed a natural
fit is more or less the first example above (throw in some error
messages if an action failed). So I poked around in the Cocoon
documentation to see if I could find syntax for doing this (as I want my
sitemap file to be as close to Cocoons as possible so people can easily
move between the two) but I couldn't find any. At least, none that used
an Action.
The thing is, by doing it the first way, you can potentially cut down on
some code reuse because instead of building two seperate chains of
components, you build one chain of components with one entry that may or
may not be there. This can become more complicated as you add more
transformers in. You could use a pipeline fragment, but that's still
somewhat more complicated and potentially slower, or you could use a
selector (at which point this would be moot, but hold on a minute!).
I was hoping there would be a good reason for not doing this: something
that would say with 100% certainty that this should NOT go into the
sitemap, because that would make my job easier. But I'm not finding the
answer.
The Ruby language developers follow the principal of least surprise.
They want the language to work as you would expect it to work. If you
think it should be possible, you should be able to figure it out without
too much difficulty using other code as an example (they strive for a
level of consistency seen in very few languages today).
So basically, it seemed surprising to me that you couldn't do this (as
it was one of the first ways I thought about using an Action).
Following that principal, I assumed there was a way to do it.
Anyway, unless somebody can convince me otherwise, I think it's a valid
thing to add to *MY* pipeline (as an alternate way of using Actions),
although I would certainly discourage it in favor of selectors. It's
just one of those things, you never know what people are going to want
to do, and I want to provide as little resistance as possible. If I
thought of it, somebody else will...
Bryan
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
