Andrzej Jan Taramina wrote:
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.
Sorry Andrzej, but the community has decided with a vote.
One of the values of the Cocoon project is to try to be philosophically right. And this is by fixing this kind of issues sooner than later that Cocoon tries to keep a clean architecture. Sure, the docs aren't what they should be to clearly document what we consider "clean". But enforcing it in the code somehow circumvents the lack of docs. Sorry if you have to cope with the consequences of this attitude this time.
The flowscript action is not in place, but you may find a convenient replacement with the ScriptAction (bsf block) that relies on BSF and as such accepts JavaScript code also. There's no "cocoon" object, but all usefull objects you normally access through "cocoon" are directly visible, such as "request", "manager", "logger", "resolver", etc.
And ever simpler solution (how did I miss this?) that came to me when going to bed (it's 11:45 pm here). Just split your request in two phases: the first one will call the flowscript in which you just add a sendPage() to the second part. This even allows you to pass the VB execution result or other flow values to the view.
As you can see, Cocoon enforces clean architectures but doesn't neglect its users. I hope the gazillion users of your multi-million project will be thankfull for the free (as in both "free beer" and "free speech") private time I dedicated to them.
Really going to bed now...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
