Ralph Goers pisze:
Grzegorz Kossakowski wrote:
Just to be sure, do you want to implement something like:
<map:match pattern="sth">
<map:call function="prepareData"/>
<map:generate src="..."/> <- some protocol to obtain the prepared data
[...]
</map:match>
Such construct introduces new semantics for sitemap because data
returned by <map:call> will be available _outside_ <map:call> element.
Now it is important what is the scope where the data will be visible.
Have you thought about it already?
Actually, I have been thinking about this for a while as I have been
toying about trying to figure out the best way to integrate Spring
webflow with cocoon. One option was to use the Interpreter interface
(which seemed very awkward, since this isn't really an interpreter) and
use map:call. IIRC, it seemed that most (all?) of the flowscript usages
I looked at don't follow the paradigm above. Rather, map:call is sort of
an end point. It invokes other Cocoon pipelines to generate views but a
pipeline doesn't follow it in the sitemap. I actually prefer this over
the above. All this syntax does is provide a little bit more flexible
action while still encouraging users to use the sitemap as the complete
controller, even for business logic, which I hope we all know by now is
a mistake.
I understand your point and even share it. ;)
I asked about that syntax because of deja vu effect (I have been reading some
related discussions in archives to see what people said earlier).
After re-reading Ellis'es original proposal I would say that I'm more than fine
with it. Go ahead, Ellis!
Instead, I would simply like to see map:call expanded so that the target
function can be a bit more generic than an Interpreter (i.e - it is
easier to implement things like the JSF block, which uses an action or
Spring webflow).
What more generic than Interpreter interface you need?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
