From: Sylvain Wallez > Andrzej Jan Taramina wrote: > > >>What do you think of the CopySourceAction I've added (see > [1])? Doing > >>the equivalent of your saveToFile.flow should be pretty trivial, no? > >> > >> > > > >It's not a bad idea, except that I still will need to use > flowscript to > >fire off a .vbs script that prints the document....or need > to write a custom action to do that, which I would rather not > do at the moment, deadlines looming and all that. > > > > > > 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. > > >>Congrats for your project. But I really think this unspecified > >>behaviour you're using is not the good way to go. So let's > keep it as is in the upcoming 2.1.3 and forbid it in 2.1.4. > >> > >> > > > >Why forbid it? I see no reason to elminate such a useful feature, > >unspecified or otherwise. > > > > > > 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. > > 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. > > 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?
With me we are already two ... I don't like this behaviour and we never agreed on this. So here my +1 to remove this behaviour for the 2.1.3 release. -- Reinhard
