Leszek Gawron wrote:
Daniel Fagerstrom wrote:
<snip/>
Concerning the strange difference between cocoon.request and request I have some slight remembrance that it has been discussed on the list and that it was deliberate. But I don't remember the reason and I have not been able to find the relevant posts.
There are two things whiche are not consistent: - request vs. cocoon.request. The latter does not work if you do not have a flowscript controller up front. - parameters vs. cocoon.parameters. First one is visible as Parameters, second one as Properties. so: ${parameters.param1} does not work !{cocoon.parameters.param1} does. ${parameters.getParameter('param1', 'default') is a proper syntax for passing a default value ${cocoon.parameters.getProperty('param1', 'default'} should do the same for cocoon.parameters.
I think we have to dive into the flow code and see why it not works whithout flow controller and fix it.
I haven't checked yet if there are issues with session.
As the use of request etc without cocoon prefix is deprecated, I don't think there is any reasons to support it in our template work that probably is directed to 2.2. So if no one protest I think we should
Is it? As the cocoon.request does not work in all cases this is hard to believe this decision has been made.
I haven't been able to find a vote about it, but I remember that it was a decision about it some time, and both in the documentation and in the code there are comments about request etc being deprecated and that cocoon.request is the supported syntax. And as a result we should make that syntax work. Hopefully someone with more knowledge about FOM can give some input.
/Daniel
