> Why do you need flowscript to fire a vb script? It should be possible to do it > in Java, and the action code should not be far from a cut'n paste of the > flowscript code.
I don't...it was just more convenient rather than compiling Java code. I plan to turn my flowscript into a Java action as a result. > There's been a discussion about this, and we agreed on the fact that he > semantics of <map:call function> and <map:call> continuation implied > that it _must_ redirect somewhere using sendPage, sendPageAndWait or > redirectTo. True...but why lock it down in 2.1.3 and piss of a VERY large customer/user base? I think the gradual phasing out, where it's discouraged in 2.1.3 and prevented in 2.1.4 makes a lot of sense. > The semantics you would like is the one of an action. I proposed to add > a "flowscript action" that would share function and global variable > scopes with the flowscript but have the appropriate contract of > returning a Map of values to the sitemap. Will this be in place in 2.1.3? If not then I would suggest that precluding the use of this unspecified behaviour prior to delivering the flowscript action is irresponsible to large, devoted Cocoon users and will win you little good will in the community. Regardless of how "philosopically" right the course of action might be in your eyes. > So the flowscript call semantics will be strengthened in the 2.1.4 to > avoid abuses of this unspecified behaviour. And the fact that you > already rely on this behaviour shows that we must correct things quickly. > > If it was only me, we would forbid it ASAP for the 2.1.3 release. What > do others think? Only if you deliver the flowscript action in 2.1.3. Then I won't have a problem with you forbidding it sooner. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
