If you ask me, this is mainly a semantic problem, not a technical one.
If a template is not called from a (Javascript) flowscript, there is no FOM, and therefore no FOM variables are available in JXTG. For the case where it _is_ called from a flowscript, then the FOM is and IMO should be accessible.
The request, session, etc, variables that are described as deprecated are unnecessary and inappropriate when the template is called from the flowscript (since they provide no additional information beyond the FOM, but yet have an "impedance mismatch" with the flowscript model). They are simply carried over from the original (pre-FOM) implementation for backward compatibility.
As I stated in the original thread about this, if someone feels that it is appropriate to call JXTG from some other context then they need to define the model that makes sense in that context and document it.
As far as the technical problem, the variable context provided to the template needs to be made configurable (in the case where it is called from a flowscript the configuration would match the current behavior). In the case where it is called from another context then a suitable configuration for that context can be provided.
However, I think you should discuss the details of some specific use cases of using JXTG without flowscript (for example JavaFlow - what exactly is its model?), before attempting to implement configurable variable contexts for JXTG.
Hope this helps and regards,
Chris
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
