cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RFC] JXTG Refactoring
Date Wed, 15 Dec 2004 10:00:51 GMT
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



Mime
View raw message