You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/06/14 12:01:38 UTC
[VOTE] Unrestricting the FOM
Hi all,
More and more, the limitations of objects provided by the FOM seem like
arbitrary constraints that go in the way of people and produce
confusion. Furthermore, these restrictions only apply to the JS
flowscript and not to JavaFlow, thus making JS flowscript a second zone
citizen compared to Java code.
That's why I propose to remove these restrictions my having
cocoon.request, cocoon.response and cocoon.context providing the full
API defined by the interfaces in org.apache.cocoon.environment.
Furthermore, I propose to add cocoon.avalonContext to provide access to
the various data held by this object.
More background on this subject is available in the "Less is more... or
less" discussion [1] and my answer to Jeremy's problem [2] that shows
how simple it is to workaround the restricted FOM.
Please cast your votes!
- [ ] to remove restrictions on existing objects.
- [ ] to add cocoon.avalonContext.
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107995167207822&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108716209403338&w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremy Quinn wrote:
<snip/>
> I made o.a.c.components.ContextHelper Contextualizable, and added the
> getAvalonContext() method. It all compiles but is not tested from
> FlowScript yet.
>
> I have to get on with some other stuff right now, but hope to have
> this tested and committed by this evening (unless there are objections).
+1!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 15 Jun 2004, at 11:27, Jeremy Quinn wrote:
>
> On 15 Jun 2004, at 10:57, Sylvain Wallez wrote:
>
>> Jeremy Quinn wrote:
>>
>>>
>>> On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
>>>
>>
>> <snip/>
>>
>>>> Looking at the vote results, the general opinion is to remove the
>>>> API restrictions (got only +1's),
>>>
>>>
>>> Good
>>>
>>>> but not tie the FOM to a particular Avalon object (got lots of +0's
>>>> and a -1).
>>>
>>>
>>> This is more difficult to understand, but I could see why some were
>>> worried.
>>>
>>>> So let's drop this cocoon.avalonContext proposal. Firstly because
>>>> it becomes less useful if the FOM is unrestricted, and secondly
>>>> because we can easily add the ContextAccess I proposed to Jeremy as
>>>> a utility class. People using that class will know by doing so that
>>>> their app becomes tied to Avalon.
>>>
>>>
>>> That is fine by me.
>>>
>>> Shall I commit the sample class you provided?
>>> Do you have any preferences for where it should live?
>>> Or do you have a more sophisticated way of adding this
>>> functionality, that you would prefer to use instead?
>>
>>
>> I see two possible locations for this code:
>> - in a new o.a.c.components.flow.util.AvalonContextAccessor class
>> (note the explicit mention to Avalon to clearly show the dependency
>> on the framework)
>
> I can understand this one
>
>> - in o.a.c.components.ContextHelper, which alread holds a number of
>> context-related methods.
>
> I am not quite sure how this functionality would get added to
> o.a.c.components.ContextHelper.
>
> It currently has all static methods, which are passed an existing
> org.apache.avalon.framework.context.Context Object.
>
>> The second solution has the benefit of concentrating all
>> Context-related features in a single class and so has my preference.
>
> Are you suggesting that this class be made Contextualizable and be
> given a getContext() method ?
>
> So to use it for getting a Context, you would call
> cocoon.createObject (ContextHelper).getContext ()
> on it?
OK
I made o.a.c.components.ContextHelper Contextualizable, and added the
getAvalonContext() method. It all compiles but is not tested from
FlowScript yet.
I have to get on with some other stuff right now, but hope to have this
tested and committed by this evening (unless there are objections).
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 15 Jun 2004, at 10:57, Sylvain Wallez wrote:
> Jeremy Quinn wrote:
>
>>
>> On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
>>
>
> <snip/>
>
>>> Looking at the vote results, the general opinion is to remove the
>>> API restrictions (got only +1's),
>>
>>
>> Good
>>
>>> but not tie the FOM to a particular Avalon object (got lots of +0's
>>> and a -1).
>>
>>
>> This is more difficult to understand, but I could see why some were
>> worried.
>>
>>> So let's drop this cocoon.avalonContext proposal. Firstly because it
>>> becomes less useful if the FOM is unrestricted, and secondly because
>>> we can easily add the ContextAccess I proposed to Jeremy as a
>>> utility class. People using that class will know by doing so that
>>> their app becomes tied to Avalon.
>>
>>
>> That is fine by me.
>>
>> Shall I commit the sample class you provided?
>> Do you have any preferences for where it should live?
>> Or do you have a more sophisticated way of adding this functionality,
>> that you would prefer to use instead?
>
>
> I see two possible locations for this code:
> - in a new o.a.c.components.flow.util.AvalonContextAccessor class
> (note the explicit mention to Avalon to clearly show the dependency on
> the framework)
I can understand this one
> - in o.a.c.components.ContextHelper, which alread holds a number of
> context-related methods.
I am not quite sure how this functionality would get added to
o.a.c.components.ContextHelper.
It currently has all static methods, which are passed an existing
org.apache.avalon.framework.context.Context Object.
> The second solution has the benefit of concentrating all
> Context-related features in a single class and so has my preference.
Are you suggesting that this class be made Contextualizable and be
given a getContext() method ?
So to use it for getting a Context, you would call
cocoon.createObject (ContextHelper).getContext ()
on it?
Thanks
regards Jeremy
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremy Quinn wrote:
>
> On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
>
<snip/>
>> Looking at the vote results, the general opinion is to remove the API
>> restrictions (got only +1's),
>
>
> Good
>
>> but not tie the FOM to a particular Avalon object (got lots of +0's
>> and a -1).
>
>
> This is more difficult to understand, but I could see why some were
> worried.
>
>> So let's drop this cocoon.avalonContext proposal. Firstly because it
>> becomes less useful if the FOM is unrestricted, and secondly because
>> we can easily add the ContextAccess I proposed to Jeremy as a utility
>> class. People using that class will know by doing so that their app
>> becomes tied to Avalon.
>
>
> That is fine by me.
>
> Shall I commit the sample class you provided?
> Do you have any preferences for where it should live?
> Or do you have a more sophisticated way of adding this functionality,
> that you would prefer to use instead?
I see two possible locations for this code:
- in a new o.a.c.components.flow.util.AvalonContextAccessor class (note
the explicit mention to Avalon to clearly show the dependency on the
framework)
- in o.a.c.components.ContextHelper, which alread holds a number of
context-related methods.
The second solution has the benefit of concentrating all Context-related
features in a single class and so has my preference.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Hi all,
>>>
>>> More and more, the limitations of objects provided by the FOM seem
>>> like arbitrary constraints that go in the way of people and produce
>>> confusion. Furthermore, these restrictions only apply to the JS
>>> flowscript and not to JavaFlow, thus making JS flowscript a second
>>> zone citizen compared to Java code.
>>>
>>> That's why I propose to remove these restrictions my having
>>> cocoon.request, cocoon.response and cocoon.context providing the
>>> full API defined by the interfaces in org.apache.cocoon.environment.
>>>
>>> Furthermore, I propose to add cocoon.avalonContext to provide access
>>> to the various data held by this object.
>>>
>>> More background on this subject is available in the "Less is more...
>>> or less" discussion [1] and my answer to Jeremy's problem [2] that
>>> shows how simple it is to workaround the restricted FOM.
>>>
>>> Please cast your votes!
>>>
>>> - [+1] to remove restrictions on existing objects.
>>> - [?] to add cocoon.avalonContext.
>>
>>
>> I'm not sure about avalonContext.`What happens if we really drop
>> Avalon as base framework? Do statements containing
>> cocoon.avalonContext still work or will they be hidden (because
>> Flowscript is interpreted) broken? If the user has to use the
>> workaround and she recompiles the code with Cocoon 3.0 and the
>> compiler doesn't compile her code anymore, she knows that she has a
>> problem. Or will a possible legacy mode hide that she may have a
>> problem?
>>
>> We should really try to make moving from Cocoon 2.x to 3.x as smooth
>> as possible and users that only use Flowscripts and the sitemap
>> shouldn't be forced to change their applications if they want to use
>> Cocoon in the same way as they have been used to do.
>
>
> Looking at the vote results, the general opinion is to remove the API
> restrictions (got only +1's),
Good
> but not tie the FOM to a particular Avalon object (got lots of +0's
> and a -1).
This is more difficult to understand, but I could see why some were
worried.
> So let's drop this cocoon.avalonContext proposal. Firstly because it
> becomes less useful if the FOM is unrestricted, and secondly because
> we can easily add the ContextAccess I proposed to Jeremy as a utility
> class. People using that class will know by doing so that their app
> becomes tied to Avalon.
That is fine by me.
Shall I commit the sample class you provided?
Do you have any preferences for where it should live?
Or do you have a more sophisticated way of adding this functionality,
that you would prefer to use instead?
Thanks for your help, and thanks everyone for your votes.
regards Jeremy
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> More and more, the limitations of objects provided by the FOM seem
>> like arbitrary constraints that go in the way of people and produce
>> confusion. Furthermore, these restrictions only apply to the JS
>> flowscript and not to JavaFlow, thus making JS flowscript a second
>> zone citizen compared to Java code.
>>
>> That's why I propose to remove these restrictions my having
>> cocoon.request, cocoon.response and cocoon.context providing the full
>> API defined by the interfaces in org.apache.cocoon.environment.
>>
>> Furthermore, I propose to add cocoon.avalonContext to provide access
>> to the various data held by this object.
>>
>> More background on this subject is available in the "Less is more...
>> or less" discussion [1] and my answer to Jeremy's problem [2] that
>> shows how simple it is to workaround the restricted FOM.
>>
>> Please cast your votes!
>>
>> - [+1] to remove restrictions on existing objects.
>> - [?] to add cocoon.avalonContext.
>
>
> I'm not sure about avalonContext.`What happens if we really drop
> Avalon as base framework? Do statements containing
> cocoon.avalonContext still work or will they be hidden (because
> Flowscript is interpreted) broken? If the user has to use the
> workaround and she recompiles the code with Cocoon 3.0 and the
> compiler doesn't compile her code anymore, she knows that she has a
> problem. Or will a possible legacy mode hide that she may have a problem?
>
> We should really try to make moving from Cocoon 2.x to 3.x as smooth
> as possible and users that only use Flowscripts and the sitemap
> shouldn't be forced to change their applications if they want to use
> Cocoon in the same way as they have been used to do.
Looking at the vote results, the general opinion is to remove the API
restrictions (got only +1's), but not tie the FOM to a particular Avalon
object (got lots of +0's and a -1).
So let's drop this cocoon.avalonContext proposal. Firstly because it
becomes less useful if the FOM is unrestricted, and secondly because we
can easily add the ContextAccess I proposed to Jeremy as a utility
class. People using that class will know by doing so that their app
becomes tied to Avalon.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Hi all,
>
> More and more, the limitations of objects provided by the FOM seem
> like arbitrary constraints that go in the way of people and produce
> confusion. Furthermore, these restrictions only apply to the JS
> flowscript and not to JavaFlow, thus making JS flowscript a second
> zone citizen compared to Java code.
>
> That's why I propose to remove these restrictions my having
> cocoon.request, cocoon.response and cocoon.context providing the full
> API defined by the interfaces in org.apache.cocoon.environment.
>
> Furthermore, I propose to add cocoon.avalonContext to provide access
> to the various data held by this object.
>
> More background on this subject is available in the "Less is more...
> or less" discussion [1] and my answer to Jeremy's problem [2] that
> shows how simple it is to workaround the restricted FOM.
>
> Please cast your votes!
>
> - [+1] to remove restrictions on existing objects.
> - [?] to add cocoon.avalonContext.
I'm not sure about avalonContext.`What happens if we really drop Avalon
as base framework? Do statements containing cocoon.avalonContext still
work or will they be hidden (because Flowscript is interpreted) broken?
If the user has to use the workaround and she recompiles the code with
Cocoon 3.0 and the compiler doesn't compile her code anymore, she knows
that she has a problem. Or will a possible legacy mode hide that she may
have a problem?
We should really try to make moving from Cocoon 2.x to 3.x as smooth as
possible and users that only use Flowscripts and the sitemap shouldn't
be forced to change their applications if they want to use Cocoon in the
same way as they have been used to do.
WDYT?
--
Reinhard
Re: [VOTE] Unrestricting the FOM
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> - [+1] to remove restrictions on existing objects.
> - [+0] to add cocoon.avalonContext.
Re: [VOTE] Unrestricting the FOM
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 09 Feb 2005 16:32:28 +0100, Sylvain Wallez <sy...@apache.org> wrote:
<snip/>
> >>cocoon.request, cocoon.response, cocoon.context and cocoon.session are
> >>now unrestricted.
> >>
> >>The only difference with the real objects is that a special wrapper is
> >>used for request, response and context that shows their respective
> >>attributes are JS properties (not sure I personally like it, but that's
> >>how they have been since the beginning).
> >>
> >>This closes a lot of open bugs ;-)
<snip/>
>
> This is in both releases (committing in 2.2 right now).
>
Great. Now all we need is a 2.1.x release. (Hint, hint...)
--
Peter Hunsberger
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Peter Hunsberger wrote:
>On Wed, 09 Feb 2005 16:05:26 +0100, Sylvain Wallez <sy...@apache.org> wrote:
>
>
>>Hi team,
>>
>>Several months later, it's done (the vote started on 14-06-2004).
>>
>>cocoon.request, cocoon.response, cocoon.context and cocoon.session are
>>now unrestricted.
>>
>>The only difference with the real objects is that a special wrapper is
>>used for request, response and context that shows their respective
>>attributes are JS properties (not sure I personally like it, but that's
>>how they have been since the beginning).
>>
>>This closes a lot of open bugs ;-)
>>
>>
>
>Many thanks!
>
>Is this in 2.2 only? If so, any chance that this will show up in a 2.1.x branch?
>If it's in 2.1.x can we get a release some time real soon pretty please?
>
This is in both releases (committing in 2.2 right now).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 09 Feb 2005 16:05:26 +0100, Sylvain Wallez <sy...@apache.org> wrote:
> Hi team,
>
> Several months later, it's done (the vote started on 14-06-2004).
>
> cocoon.request, cocoon.response, cocoon.context and cocoon.session are
> now unrestricted.
>
> The only difference with the real objects is that a special wrapper is
> used for request, response and context that shows their respective
> attributes are JS properties (not sure I personally like it, but that's
> how they have been since the beginning).
>
> This closes a lot of open bugs ;-)
Many thanks!
Is this in 2.2 only? If so, any chance that this will show up in a 2.1.x branch?
If it's in 2.1.x can we get a release some time real soon pretty please?
--
Peter Hunsberger
Re: [VOTE] Unrestricting the FOM
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Hi team,
>>>
>>> Several months later, it's done (the vote started on 14-06-2004).
>>>
>>> cocoon.request, cocoon.response, cocoon.context and cocoon.session
>>> are now unrestricted.
>>>
>>> The only difference with the real objects is that a special wrapper
>>> is used for request, response and context that shows their respective
>>> attributes are JS properties (not sure I personally like it, but
>>> that's how they have been since the beginning).
>>>
>>> This closes a lot of open bugs ;-)
>>>
>> Great! Why do we need this special wrapper?
>
>
>
> Because removing it means a backwards incompatible change!
>
> It adds small syntactic sugar by allowing you to write
> 'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")'
> and the same on request and context.
>
> I personally didn't knew about it until today and therefore never used
> it...
Lovely.
--
Stefano.
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
<snip/>
>I found time to update the SVN version and an application that works fine
>using the lastest SVN version seems to be broken.
>
>I added 2 lines in javascript flow code for test:
>
>cocoon.log.error("name=" + cocoon.request.name);
>cocoon.log.error("name=" + cocoon.request.getParameter("name"));
>
>And the result is:
>
>name=undefined
>name=antonio
>
>
>Then the original "cocoon.request.name" is not working anymore. It was
>simply a very big poof! ;-)
>
>Seriously, can you review the change just to deprecate it. :-)
>
>
Ooops, I'll fix that ASAP.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Antonio Gallardo <ag...@agssa.net>.
On Jue, 10 de Febrero de 2005, 7:51, Sylvain Wallez dijo:
> oceatoon wrote:
>
>>>>Hmm... the problems is that "cocoon.request.blah" was released and
>>>> maybe
>>>>is used is used (by us and other people?) in a lot of places and maybe
>>>>other peopl! :-(
>>>>
>>>>
>>Sorry for peecking into this post but till today I thought
>>cocoon.request.blah was a normal call, and seemed quite natural ;) in a
>>users perspective. I do use it massively.
>>
>>So the correct way of doing this would be
>>cocoon.request.getParameter("blah") then ?
>>
>>
>
> Exactly. Don't know yet how/if parameters will be available as
> properties in the future, but for sure cocoon.request.getParameter()
> will always work.
>
>>before it blows off with 2.2
>>
>>
>
> Poof :-)
What a big poof! It reached 2.1.7-dev!!! ;-)
I found time to update the SVN version and an application that works fine
using the lastest SVN version seems to be broken.
I added 2 lines in javascript flow code for test:
cocoon.log.error("name=" + cocoon.request.name);
cocoon.log.error("name=" + cocoon.request.getParameter("name"));
And the result is:
name=undefined
name=antonio
Then the original "cocoon.request.name" is not working anymore. It was
simply a very big poof! ;-)
Seriously, can you review the change just to deprecate it. :-)
Best Regards,
Antonio Gallardo
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
oceatoon wrote:
>>>Hmm... the problems is that "cocoon.request.blah" was released and maybe
>>>is used is used (by us and other people?) in a lot of places and maybe
>>>other peopl! :-(
>>>
>>>
>Sorry for peecking into this post but till today I thought
>cocoon.request.blah was a normal call, and seemed quite natural ;) in a
>users perspective. I do use it massively.
>
>So the correct way of doing this would be
>cocoon.request.getParameter("blah") then ?
>
>
Exactly. Don't know yet how/if parameters will be available as
properties in the future, but for sure cocoon.request.getParameter()
will always work.
>before it blows off with 2.2
>
>
Poof :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by oceatoon <t....@systheo.com>.
>>Hmm... the problems is that "cocoon.request.blah" was released and maybe
>>is used is used (by us and other people?) in a lot of places and maybe
>>other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite natural ;) in a
users perspective. I do use it massively.
So the correct way of doing this would be
cocoon.request.getParameter("blah") then ?
before it blows off with 2.2
Thanks
Tibor
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
>
>
<snip/>
>>Oh f*ck, that's even worse than I thought. It now returns the request
>>*attributes* because I was fooled by the implementation of FOM_Request
>>which was buggy: getIds() which lists the object's properties was
>>considering *attribute* names just as FOM_Session and FOM_Context, but
>>get() which actually gets a property was considering *parameter* names.
>>
>>What that means is that (before today's change):
>>- cocoon.context.blah == cocoon.context.getAttribute("blah")
>>- cocoon.session.blah == cocoon.session.getAttribute("blah")
>>- cocoon.request.blah == cocoon.request.getParameter("blah") and not
>>cocoon.request.getAttribute("blah").
>>
>>This is clearly inconsistent.
>>
>>Furthermore, I really don't like this naming scope filled from different
>>sources (the object itself and some other data), especially when one of
>>the sources comes from the browser.
>>
>>And what about conflicts? Fortunately the object is searched before
>>request parameters, otherwise this would be a nice security hole.
>>
>>
>
>It was "carefully" designed. ;-)
>
>
Flowscript is a nice invention, but custom JS wrappings have been used
in weird ways...
>>So, what do we do? Do we keep this inconsistent behaviour, deprecate it,
>>remove it now?
>>
>>
>
>Hmm... the problems is that "cocoon.request.blah" was released and maybe
>is used is used (by us and other people?) in a lot of places and maybe
>other peopl! :-(
>
>I think the best is to keep the 2.1.x "as is" and perhas deprecate it in
>the next (2.1.7) release and remove it in 2.2.
>
>
Yep. Sounds reasonable.
>[Antonio while typing, pausing to answer customer's questions by phone saw
>that Sylvain already fixed the problem. Antonio is very happy and wants to
>test the last change.]
>
>...
>
>Anyway, you are faster than me! I already saw the last patch. I will check
>if it is working now as expected. Mr. Incredible, thanks for you time! ;-)
>
>
Well, I don't have that much time for Cocoon development lately
(although I'm using it for very fancy stuff), but one thing I really
hate is leaving bugs unfixed in what I wrote once I've identified them ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>
>>On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
>>
>>
>>>Carsten Ziegeler wrote:
>>>
>>>
>>>
>>>>Sylvain Wallez wrote:
>>>>
>>>>
>>>>
>>>>>Hi team,
>>>>>
>>>>>Several months later, it's done (the vote started on 14-06-2004).
>>>>>
>>>>>cocoon.request, cocoon.response, cocoon.context and cocoon.session
>>>>>are now unrestricted.
>>>>>
>>>>>The only difference with the real objects is that a special wrapper
>>>>>is used for request, response and context that shows their respective
>>>>>attributes are JS properties (not sure I personally like it, but
>>>>>that's how they have been since the beginning).
>>>>>
>>>>>This closes a lot of open bugs ;-)
>>>>>
>>>>>
>>>>>
>>>>Great! Why do we need this special wrapper?
>>>>
>>>>
>>>Because removing it means a backwards incompatible change!
>>>
>>>It adds small syntactic sugar by allowing you to write
>>>'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")'
>>>and the same on request and context.
>>>
>>>I personally didn't knew about it until today and therefore never used
>>>it...
>>>
>>>
>>
>>I thought in the form flow samples is. The construction is often used to
>>test request params. ;-)
>>
>>ie: cocoon.request.myButton
>>
>>
>
> Oh f*ck, that's even worse than I thought. It now returns the request
> *attributes* because I was fooled by the implementation of FOM_Request
> which was buggy: getIds() which lists the object's properties was
> considering *attribute* names just as FOM_Session and FOM_Context, but
> get() which actually gets a property was considering *parameter* names.
>
> What that means is that (before today's change):
> - cocoon.context.blah == cocoon.context.getAttribute("blah")
> - cocoon.session.blah == cocoon.session.getAttribute("blah")
> - cocoon.request.blah == cocoon.request.getParameter("blah") and not
> cocoon.request.getAttribute("blah").
>
> This is clearly inconsistent.
>
> Furthermore, I really don't like this naming scope filled from different
> sources (the object itself and some other data), especially when one of
> the sources comes from the browser.
>
> And what about conflicts? Fortunately the object is searched before
> request parameters, otherwise this would be a nice security hole.
It was "carefully" designed. ;-)
> So, what do we do? Do we keep this inconsistent behaviour, deprecate it,
> remove it now?
Hmm... the problems is that "cocoon.request.blah" was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
I think the best is to keep the 2.1.x "as is" and perhas deprecate it in
the next (2.1.7) release and remove it in 2.2.
...
[Antonio while typing, pausing to answer customer's questions by phone saw
that Sylvain already fixed the problem. Antonio is very happy and wants to
test the last change.]
...
Anyway, you are faster than me! I already saw the last patch. I will check
if it is working now as expected. Mr. Incredible, thanks for you time! ;-)
Best Regards,
Antonio Gallardo
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 févr. 05, à 21:27, Carsten Ziegeler a écrit :
> ...Unfortunately, I fear that this is common use, so let's deprecate
> it with 2.1.x and remove for 2.2 completly
+1
-Bertrand
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
>>
> I think this should be as simple as possible. What about a static
> accessor, e.g. on the Core object?
I meant the Cocoon object here (we are talking about 2.1.x).
> You might want to use this logger
> where you don't want to either implement Serviceable nor
> Contextualizable, so imho it should be easier.
>
> Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> I mean not tied to a class that provides other features than deprecation
> logging. And the "Cocoon" class provides so much more ;-)
>
> Hence the specific Deprecation class below, which will of course be in
> the org.apache.cocoon package hierarchy.
>
Ok: +1 - I would choose a different name than Deprecation
(DeprecationUtil or DeprecationLogger), but that's not that important.
Choose whatever you think is best.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Thinking further, I don't think we should attach this to the Cocoon
>> object as we may want to use this in classes also used outside the
>> Cocoon machinery.
>>
> Outside the Cocoon machinery? What do you mean by this?
I mean not tied to a class that provides other features than deprecation
logging. And the "Cocoon" class provides so much more ;-)
Hence the specific Deprecation class below, which will of course be in
the org.apache.cocoon package hierarchy.
>> So what about a dedicated o.a.c.util.Deprecation class?
>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Thinking further, I don't think we should attach this to the Cocoon
> object as we may want to use this in classes also used outside the
> Cocoon machinery.
>
Outside the Cocoon machinery? What do you mean by this?
> So what about a dedicated o.a.c.util.Deprecation class?
>
> Sylvain
>
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>
>
>>> Now with all this deprecated stuff floating around, we should have a
>>> centralized deprecation Logger so that users can easily be informed
>>> of the deprecated features they use (in the case of Javascript,
>>> there's no compiler warning like in Java).
>>>
>>> That would make a new log file (e.g. deprecated.log), but IMO that
>>> one deserves to exist.
>>
>>
>>
>> Yes, and we should really try to add *all* "deprecated log messages"
>> there.
>
>
>
> And punish those that fail to use it once it's in place ;-)
>
>>> Where can we put that deprecation logger? What comes to mind is
>>> either the Avalon Context, or a component, i.e. lookup(Logger.ROLE +
>>> "deprecated").
>>>
>>> WDYT?
>>
>>
>> I think this should be as simple as possible. What about a static
>> accessor, e.g. on the Core object? You might want to use this logger
>> where you don't want to either implement Serviceable nor
>> Contextualizable, so imho it should be easier.
>
>
> Yeah, I thought about a static accessor also, but I'm fearing some
> problems with classloading. Well, if any such problem arises, we'll be
> able to solve it withing the accessor's code.
>
> So let's go for Cocoon.getDeprecationLogger().
Thinking further, I don't think we should attach this to the Cocoon
object as we may want to use this in classes also used outside the
Cocoon machinery.
So what about a dedicated o.a.c.util.Deprecation class?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>> Now with all this deprecated stuff floating around, we should have a
>> centralized deprecation Logger so that users can easily be informed
>> of the deprecated features they use (in the case of Javascript,
>> there's no compiler warning like in Java).
>>
>> That would make a new log file (e.g. deprecated.log), but IMO that
>> one deserves to exist.
>
>
> Yes, and we should really try to add *all* "deprecated log messages"
> there.
And punish those that fail to use it once it's in place ;-)
>> Where can we put that deprecation logger? What comes to mind is
>> either the Avalon Context, or a component, i.e. lookup(Logger.ROLE +
>> "deprecated").
>>
>> WDYT?
>
>
> I think this should be as simple as possible. What about a static
> accessor, e.g. on the Core object? You might want to use this logger
> where you don't want to either implement Serviceable nor
> Contextualizable, so imho it should be easier.
Yeah, I thought about a static accessor also, but I'm fearing some
problems with classloading. Well, if any such problem arises, we'll be
able to solve it withing the accessor's code.
So let's go for Cocoon.getDeprecationLogger().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>>
>>> This is clearly inconsistent.
>>
>>
>> Yepp
>>
>>>
>>> Furthermore, I really don't like this naming scope filled from
>>> different sources (the object itself and some other data), especially
>>> when one of the sources comes from the browser.
>>>
>>> And what about conflicts? Fortunately the object is searched before
>>> request parameters, otherwise this would be a nice security hole.
>>>
>>> So, what do we do? Do we keep this inconsistent behaviour, deprecate
>>> it, remove it now?
>>>
>>> WDYT?
>>>
>> I personally would remove this syntactic sugar completly; it's imho
>> not intuitiv what it means and the inconsistent implementation adds to
>> it.
>> In addition it would make our unified object model implementation (for
>> flow, jxtg etc.) much easier as we don't have to simulate this in Java.
>>
>> Unfortunately, I fear that this is common use, so let's deprecate it
>> with 2.1.x and remove for 2.2 completly
>
>
>
> agree :-)
>
> Now with all this deprecated stuff floating around, we should have a
> centralized deprecation Logger so that users can easily be informed of
> the deprecated features they use (in the case of Javascript, there's no
> compiler warning like in Java).
>
> That would make a new log file (e.g. deprecated.log), but IMO that one
> deserves to exist.
>
Yes, and we should really try to add *all* "deprecated log messages" there.
> Where can we put that deprecation logger? What comes to mind is either
> the Avalon Context, or a component, i.e. lookup(Logger.ROLE +
> "deprecated").
>
> WDYT?
>
I think this should be as simple as possible. What about a static
accessor, e.g. on the Core object? You might want to use this logger
where you don't want to either implement Serviceable nor
Contextualizable, so imho it should be easier.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>>>
>>> I personally would remove this syntactic sugar completly; it's imho
>>> not intuitiv what it means and the inconsistent implementation adds
>>> to it.
>>> In addition it would make our unified object model implementation
>>> (for flow, jxtg etc.) much easier as we don't have to simulate this
>>> in Java.
>>>
>>> Unfortunately, I fear that this is common use, so let's deprecate it
>>> with 2.1.x and remove for 2.2 completly
>>
>>
>> agree :-)
>>
> We have the same functionality in flow, e.g. you can get the value of
> a widget using the model with "model.WIDGETID". I think we should
> deprecate (and remove) this as well.
Yep. We have form.model that gives access to a JS-specific API of
widgets which does have its set of inconsistencies.
> Can you start a formal vote about it?
Yup.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>>>
>> I personally would remove this syntactic sugar completly; it's imho
>> not intuitiv what it means and the inconsistent implementation adds to
>> it.
>> In addition it would make our unified object model implementation (for
>> flow, jxtg etc.) much easier as we don't have to simulate this in Java.
>>
>> Unfortunately, I fear that this is common use, so let's deprecate it
>> with 2.1.x and remove for 2.2 completly
>
>
>
> agree :-)
>
We have the same functionality in flow, e.g. you can get the value of a
widget using the model with "model.WIDGETID". I think we should
deprecate (and remove) this as well.
Can you start a formal vote about it?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>
>> This is clearly inconsistent.
>
> Yepp
>
>>
>> Furthermore, I really don't like this naming scope filled from
>> different sources (the object itself and some other data), especially
>> when one of the sources comes from the browser.
>>
>> And what about conflicts? Fortunately the object is searched before
>> request parameters, otherwise this would be a nice security hole.
>>
>> So, what do we do? Do we keep this inconsistent behaviour, deprecate
>> it, remove it now?
>>
>> WDYT?
>>
> I personally would remove this syntactic sugar completly; it's imho
> not intuitiv what it means and the inconsistent implementation adds to
> it.
> In addition it would make our unified object model implementation (for
> flow, jxtg etc.) much easier as we don't have to simulate this in Java.
>
> Unfortunately, I fear that this is common use, so let's deprecate it
> with 2.1.x and remove for 2.2 completly
agree :-)
Now with all this deprecated stuff floating around, we should have a
centralized deprecation Logger so that users can easily be informed of
the deprecated features they use (in the case of Javascript, there's no
compiler warning like in Java).
That would make a new log file (e.g. deprecated.log), but IMO that one
deserves to exist.
Where can we put that deprecation logger? What comes to mind is either
the Avalon Context, or a component, i.e. lookup(Logger.ROLE + "deprecated").
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> This is clearly inconsistent.
Yepp
>
> Furthermore, I really don't like this naming scope filled from different
> sources (the object itself and some other data), especially when one of
> the sources comes from the browser.
>
> And what about conflicts? Fortunately the object is searched before
> request parameters, otherwise this would be a nice security hole.
>
> So, what do we do? Do we keep this inconsistent behaviour, deprecate it,
> remove it now?
>
> WDYT?
>
I personally would remove this syntactic sugar completly; it's imho not
intuitiv what it means and the inconsistent implementation adds to it.
In addition it would make our unified object model implementation (for
flow, jxtg etc.) much easier as we don't have to simulate this in Java.
Unfortunately, I fear that this is common use, so let's deprecate it
with 2.1.x and remove for 2.2 completly
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>
>>>Sylvain Wallez wrote:
>>>
>>>
>>>
>>>>Hi team,
>>>>
>>>>Several months later, it's done (the vote started on 14-06-2004).
>>>>
>>>>cocoon.request, cocoon.response, cocoon.context and cocoon.session
>>>>are now unrestricted.
>>>>
>>>>The only difference with the real objects is that a special wrapper
>>>>is used for request, response and context that shows their respective
>>>>attributes are JS properties (not sure I personally like it, but
>>>>that's how they have been since the beginning).
>>>>
>>>>This closes a lot of open bugs ;-)
>>>>
>>>>
>>>>
>>>Great! Why do we need this special wrapper?
>>>
>>>
>>Because removing it means a backwards incompatible change!
>>
>>It adds small syntactic sugar by allowing you to write
>>'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")'
>>and the same on request and context.
>>
>>I personally didn't knew about it until today and therefore never used
>>it...
>>
>>
>
>I thought in the form flow samples is. The construction is often used to
>test request params. ;-)
>
>ie: cocoon.request.myButton
>
>
Oh f*ck, that's even worse than I thought. It now returns the request
*attributes* because I was fooled by the implementation of FOM_Request
which was buggy: getIds() which lists the object's properties was
considering *attribute* names just as FOM_Session and FOM_Context, but
get() which actually gets a property was considering *parameter* names.
What that means is that (before today's change):
- cocoon.context.blah == cocoon.context.getAttribute("blah")
- cocoon.session.blah == cocoon.session.getAttribute("blah")
- cocoon.request.blah == cocoon.request.getParameter("blah") and not
cocoon.request.getAttribute("blah").
This is clearly inconsistent.
Furthermore, I really don't like this naming scope filled from different
sources (the object itself and some other data), especially when one of
the sources comes from the browser.
And what about conflicts? Fortunately the object is searched before
request parameters, otherwise this would be a nice security hole.
So, what do we do? Do we keep this inconsistent behaviour, deprecate it,
remove it now?
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Hi team,
>>>
>>> Several months later, it's done (the vote started on 14-06-2004).
>>>
>>> cocoon.request, cocoon.response, cocoon.context and cocoon.session
>>> are now unrestricted.
>>>
>>> The only difference with the real objects is that a special wrapper
>>> is used for request, response and context that shows their respective
>>> attributes are JS properties (not sure I personally like it, but
>>> that's how they have been since the beginning).
>>>
>>> This closes a lot of open bugs ;-)
>>>
>> Great! Why do we need this special wrapper?
>
>
> Because removing it means a backwards incompatible change!
>
> It adds small syntactic sugar by allowing you to write
> 'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")'
> and the same on request and context.
>
> I personally didn't knew about it until today and therefore never used
> it...
I thought in the form flow samples is. The construction is often used to
test request params. ;-)
ie: cocoon.request.myButton
Best Regards,
Antonio Gallardo
Re: [VOTE] Unrestricting the FOM
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>> Great! Why do we need this special wrapper?
>
>
>
> Because removing it means a backwards incompatible change!
>
Sounds familiar ;)
> It adds small syntactic sugar by allowing you to write
> 'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")'
> and the same on request and context.
>
Ah, right - thanks.
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Hi team,
>>
>> Several months later, it's done (the vote started on 14-06-2004).
>>
>> cocoon.request, cocoon.response, cocoon.context and cocoon.session
>> are now unrestricted.
>>
>> The only difference with the real objects is that a special wrapper
>> is used for request, response and context that shows their respective
>> attributes are JS properties (not sure I personally like it, but
>> that's how they have been since the beginning).
>>
>> This closes a lot of open bugs ;-)
>>
> Great! Why do we need this special wrapper?
Because removing it means a backwards incompatible change!
It adds small syntactic sugar by allowing you to write
'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")'
and the same on request and context.
I personally didn't knew about it until today and therefore never used it...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Hi team,
>
> Several months later, it's done (the vote started on 14-06-2004).
>
> cocoon.request, cocoon.response, cocoon.context and cocoon.session are
> now unrestricted.
>
> The only difference with the real objects is that a special wrapper is
> used for request, response and context that shows their respective
> attributes are JS properties (not sure I personally like it, but that's
> how they have been since the beginning).
>
> This closes a lot of open bugs ;-)
>
Great! Why do we need this special wrapper?
Carsten
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is that a special wrapper is
used for request, response and context that shows their respective
attributes are JS properties (not sure I personally like it, but that's
how they have been since the beginning).
This closes a lot of open bugs ;-)
Sylvain
Sylvain Wallez wrote:
> Hi all,
>
> More and more, the limitations of objects provided by the FOM seem
> like arbitrary constraints that go in the way of people and produce
> confusion. Furthermore, these restrictions only apply to the JS
> flowscript and not to JavaFlow, thus making JS flowscript a second
> zone citizen compared to Java code.
>
> That's why I propose to remove these restrictions my having
> cocoon.request, cocoon.response and cocoon.context providing the full
> API defined by the interfaces in org.apache.cocoon.environment.
>
> Furthermore, I propose to add cocoon.avalonContext to provide access
> to the various data held by this object.
>
> More background on this subject is available in the "Less is more...
> or less" discussion [1] and my answer to Jeremy's problem [2] that
> shows how simple it is to workaround the restricted FOM.
>
> Please cast your votes!
>
> - [ ] to remove restrictions on existing objects.
> - [ ] to add cocoon.avalonContext.
>
> Sylvain
>
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107995167207822&w=2
> [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108716209403338&w=2
>
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Tony Collen <co...@umn.edu>.
Joerg Heinicke wrote:
> [+1] to remove restrictions on existing objects.
> [+0] to add cocoon.avalonContext.
>
> Joerg
Same here.
Tony
Re: [VOTE] Unrestricting the FOM
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.06.2004 12:01, Sylvain Wallez wrote:
> That's why I propose to remove these restrictions my having
> cocoon.request, cocoon.response and cocoon.context providing the full
> API defined by the interfaces in org.apache.cocoon.environment.
>
> Furthermore, I propose to add cocoon.avalonContext to provide access to
> the various data held by this object.
[+1] to remove restrictions on existing objects.
[+0] to add cocoon.avalonContext.
Joerg
Re: [VOTE] Unrestricting the FOM
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 14 juin 04, à 12:01, Sylvain Wallez a écrit :
> Please cast your votes!
>
> - [ +1] to remove restrictions on existing objects.
> - [ +1] to add cocoon.avalonContext.
-Bertrand
Re: [VOTE] Unrestricting the FOM
Posted by peter royal <pr...@apache.org>.
+1 to remove restrictions on existing objects.
+0 to add cocoon.avalonContext.
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
> +1 to remove restrictions on existing objects.
> +1 to add cocoon.avalonContext.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 14 Jun 2004, at 11:01, Sylvain Wallez wrote:
> Please cast your votes!
The ease with which it can be worked around (thanks Sylvain) and the
fact this is available to JavaFlow are good arguments IMHO.
> - [ +1 ] to remove restrictions on existing objects.
> - [ +1 ] to add cocoon.avalonContext.
>
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 14 Jun 2004, at 12:11, Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>>
>> - [ ] to remove restrictions on existing objects.
> +1
>
>> - [ ] to add cocoon.avalonContext.
>
> -1 for the name "avalonContext". I think we should avoid references
> to Avalon whereever possible. Otherwise perhaps we have to rename
> it in the future.
> So, +1 if a different name is used.
call it 'framework' ?
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Makes sense. And migrating some stuff to the env-context may
>>help removing some dependencies on Avalon. But whe have to be
>>very careful about what attributes we want to move from
>>avalon-context to env-context, and be sure they will still
>>make sense in a new container and within blocks.
>>
>>
>>
>Yepp.
>
>
>>The only point I'm not sure about is the object model: should
>>it be in the env-context, since it also contains that
>>env-context? Kind of circular dependency that may be confusing...
>>
>>
>>
>Yepp, that's true. I would say we leave this in the avalon
>context then.
>
>
If we do that, we can't totally cut the dependency on avalon-context...
>>What we need actually is some kind of mini-environment that
>>would give access only to the "safe" properties of
>>o.a.c.e.Environment, i.e. mainly the object model and
>>attributes, plus access to the current avalon-context
>>attributes through type-safe getter methods.
>>
>>
Actually, this mini-environment is the object model. Too bad it's
currently an untyped Map. Or what about creating an ObjectModel class
that would be that mini-environment ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [VOTE] Unrestricting the FOM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Makes sense. And migrating some stuff to the env-context may
> help removing some dependencies on Avalon. But whe have to be
> very careful about what attributes we want to move from
> avalon-context to env-context, and be sure they will still
> make sense in a new container and within blocks.
>
Yepp.
>
> The only point I'm not sure about is the object model: should
> it be in the env-context, since it also contains that
> env-context? Kind of circular dependency that may be confusing...
>
Yepp, that's true. I would say we leave this in the avalon
context then.
> What we need actually is some kind of mini-environment that
> would give access only to the "safe" properties of
> o.a.c.e.Environment, i.e. mainly the object model and
> attributes, plus access to the current avalon-context
> attributes through type-safe getter methods.
>
> >Then in flow, cocoon.context works perfect.
> >
> >
>
> Yupp. <rt>And with an IOC type2/3 container we could even
> totally remove the dependency on avalon-context by simply have a
> setContext(o.a.c.e.Context) method ;-)</rt>
>
Yepp :), it would work today if we would move to Fortress.....
Carsten
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>
>Sylvain Wallez wrote:
>
>
>>>We already have cocoon.context, couldn't we make things available from there?
>>>
>>>
>>Mmmh... don't know if it's a good idea, as the Cocoon core currently doesn't rely on custom attributes in the environment objects (unless I'm mistaken). This would complexify things a bit, IMO.
>>
>>
>Hmm, ok we currently have a o.a.c.environment.Context which has some functions from the servlet context object and attributes. Currently these attributes are not really used.
>
>
That's what I pointed out above: the Cocoon core currently makes no use
of attributes in env-context, session and request. These are for
application use, and up to now the Cocoon core has not "polluted" these
objects.
>And we have o.a.a.context.Context which is a map containing many important information about the application.
>
>
Yep. Let's list what's in avalon-context.
The main DefaultContext is initialized with:
- Constants.CONTEXT_ENVIRONMENT_CONTEXT : the environment context (type
o.a.c.e.Context)
- Constants.CONTEXT_WORK_DIR : Cocoon's work directory (type File)
- ContextHelper.CONTEXT_ROOT_URL : the servlet context's URL (type
String - why not URL?)
- Constants.CONTEXT_UPLOAD_DIR : the upload directory (type File)
- Constants.CONTEXT_CACHE_DIR : the cache directory (type File)
- Constants.CONTEXT_CONFIG_URL : location of cocoon.xconf (type URL,
used only to initialize the Cocoon object)
- Constants.CONTEXT_DEFAULT_ENCODING : default form encoding (type String)
- Constants.CONTEXT_CLASS_LOADER : CocoonServlet's classloader (type
ClassLoader, used only to initialize the Cocoon object)
- Constants.CONTEXT_CLASSPATH : the classpath used by the XSP engine
(type String)
The actual Context seen by applications is a ComponentContext that wraps
the above DefaultContext with:
- ContextHelper.CONTEXT_OBJECT_MODEL : the current object model (type Map)
- ContextHelper.CONTEXT_SITEMAP_SERVICE_MANAGER : the current sitemap's
service manager
- ComponentContext.OBJECT_MODEL_KEY_PREFIX : prefix to access members of
the object model (could be removed, as only used in the implementation
of ContextHelper.getRequest()/getResponse())
When in HTTP environment, there's also:
- CocoonServlet.CONTEXT_SERVLET_CONFIG : the ServletConfig
When in portlet environment, there's also
- CocoonPortlet.CONTEXT_PORTLET_CONFIG: the PortletConfig
>For me it seems that two contexts is one too much :)
>
>
Makes sense. And migrating some stuff to the env-context may help
removing some dependencies on Avalon. But whe have to be very careful
about what attributes we want to move from avalon-context to
env-context, and be sure they will still make sense in a new container
and within blocks.
>So, why not combining those somehow. Currently you get the o.a.c.e.Context from the avalon context.
>
>Now, we could for example store all information we currently have in the avalon context into the environment context and using the environment context as the only reference for application information. If you need this context you can get it from the avalon context. The avalon context only contains this single piece of information (of course for compatibility we let everything remain there as well).
>
>
The only point I'm not sure about is the object model: should it be in
the env-context, since it also contains that env-context? Kind of
circular dependency that may be confusing...
What we need actually is some kind of mini-environment that would give
access only to the "safe" properties of o.a.c.e.Environment, i.e. mainly
the object model and attributes, plus access to the current
avalon-context attributes through type-safe getter methods.
>Then in flow, cocoon.context works perfect.
>
>
Yupp. <rt>And with an IOC type2/3 container we could even totally remove
the dependency on avalon-context by simply have a
setContext(o.a.c.e.Context) method ;-)</rt>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 15 Jun 2004, at 18:04, Sylvain Wallez wrote:
> Jeremy Quinn wrote:
>
> <snip/>
>
>> Should I hold back on committing my changes to make ContextHelper
>> Contextualizable, to wait to see what comes out of this proposal ?
>
>
> Wait a bit ;-)
>
> You can still use the ContextAccess class in your own source tree,
> though.
>
I am almost ready to commit the new Query Bean, and samples.
I am planning on adding it to the Lucene Block, with my classes in
org.apache.cocoon.bean.query.
While waiting for a resolution of the FOM issue discussed in this
thread, I would need to add:
org.apache.cocoon.bean.query.ContextAccess
as a temporary solution to getting an AvalonContext from within a
FlowScript.
Does anyone have an issue with this?
Thanks
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 15 Jun 2004, at 18:04, Sylvain Wallez wrote:
> Jeremy Quinn wrote:
>
> <snip/>
>
>> Should I hold back on committing my changes to make ContextHelper
>> Contextualizable, to wait to see what comes out of this proposal ?
>
>
> Wait a bit ;-)
>
> You can still use the ContextAccess class in your own source tree,
> though.
OK
>
>> BTW. I think there may be a related issue here with a problem noted a
>> while ago, where it was not possible to read parameters setup in
>> web.xml as expected using :
>>
>> org.apache.cocoon.environment.Context.getInitParameter(String
>> name)
>>
>> Unless Cocoon was 'expecting' that parameter to be there.
>>
>> I don't know if this is a bug or a just a misunderstanding ;)
>
>
> I guess you made the (sorry!) classical mistake of adding parameters
> to the Cocoon servlet instead of the _webapp context_, which is what
> is accessed using Context.getInitParameter().
Oh no :)
<blush/>
regards jeremy
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremy Quinn wrote:
<snip/>
> Should I hold back on committing my changes to make ContextHelper
> Contextualizable, to wait to see what comes out of this proposal ?
Wait a bit ;-)
You can still use the ContextAccess class in your own source tree, though.
> BTW. I think there may be a related issue here with a problem noted a
> while ago, where it was not possible to read parameters setup in
> web.xml as expected using :
>
> org.apache.cocoon.environment.Context.getInitParameter(String name)
>
> Unless Cocoon was 'expecting' that parameter to be there.
>
> I don't know if this is a bug or a just a misunderstanding ;)
I guess you made the (sorry!) classical mistake of adding parameters to
the Cocoon servlet instead of the _webapp context_, which is what is
accessed using Context.getInitParameter().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [VOTE] Unrestricting the FOM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jeremy Quinn wrote:
>
> > Currently these attributes are not really used.
>
> Ah, I though these were the context attributes you could
> access from FlowScript, as in:
> cocoon.context.setAttribute ("name", myObject); I have
> used this before ..... when I needed to share the same object
> between several users.
>
Yes, that's right. I meant Cocoon itself does not use them, it's
up to the users to make sense of them.
> >
> > And we have o.a.a.context.Context which is a map containing
> > many important information about the application.
>
> Do you mean org.apache.avalon.framework.context.Context ?
>
Yupp.
>
> Should I hold back on committing my changes to make ContextHelper
> Contextualizable, to wait to see what comes out of this proposal ?
>
Hmm, don't know - we are in development state so we can remove
it if we find a better solution before a release
Carsten
Re: [VOTE] Unrestricting the FOM
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 15 Jun 2004, at 15:57, Carsten Ziegeler wrote:
>
> Sylvain Wallez wrote:
>>
>>> We already have cocoon.context, couldn't we make things
>> available from there?
>>>
>>>
>>
>> Mmmh... don't know if it's a good idea, as the Cocoon core
>> currently doesn't rely on custom attributes in the
>> environment objects (unless I'm mistaken). This would
>> complexify things a bit, IMO.
>>
> Hmm, ok we currently have a o.a.c.environment.Context which
> has some functions from the servlet context object and attributes.
This is where I would have expected to find "work-directory", being a
Servlet-supplied parameter.
> Currently these attributes are not really used.
Ah, I though these were the context attributes you could access from
FlowScript, as in:
cocoon.context.setAttribute ("name", myObject);
I have used this before ..... when I needed to share the same object
between several users.
>
> And we have o.a.a.context.Context which is a map containing
> many important information about the application.
Do you mean org.apache.avalon.framework.context.Context ?
> For me it seems that two contexts is one too much :)
+ 1
It is rather complicated ;)
> So, why not combining those somehow. Currently you get the
> o.a.c.e.Context from the avalon context.
>
> Now, we could for example store all information we currently
> have in the avalon context into the environment context
> and using the environment context as the only reference
> for application information. If you need this context
> you can get it from the avalon context. The avalon context
> only contains this single piece of information (of course
> for compatibility we let everything remain there as
> well).
> Then in flow, cocoon.context works perfect.
>
> WDYT?
YES !!!
Should I hold back on committing my changes to make ContextHelper
Contextualizable, to wait to see what comes out of this proposal ?
BTW. I think there may be a related issue here with a problem noted a
while ago, where it was not possible to read parameters setup in
web.xml as expected using :
org.apache.cocoon.environment.Context.getInitParameter(String name)
Unless Cocoon was 'expecting' that parameter to be there.
I don't know if this is a bug or a just a misunderstanding ;)
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
RE: [VOTE] Unrestricting the FOM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> >We already have cocoon.context, couldn't we make things
> available from there?
> >
> >
>
> Mmmh... don't know if it's a good idea, as the Cocoon core
> currently doesn't rely on custom attributes in the
> environment objects (unless I'm mistaken). This would
> complexify things a bit, IMO.
>
Hmm, ok we currently have a o.a.c.environment.Context which
has some functions from the servlet context object and attributes.
Currently these attributes are not really used.
And we have o.a.a.context.Context which is a map containing
many important information about the application.
For me it seems that two contexts is one too much :)
So, why not combining those somehow. Currently you get the
o.a.c.e.Context from the avalon context.
Now, we could for example store all information we currently
have in the avalon context into the environment context
and using the environment context as the only reference
for application information. If you need this context
you can get it from the avalon context. The avalon context
only contains this single piece of information (of course
for compatibility we let everything remain there as
well).
Then in flow, cocoon.context works perfect.
WDYT?
Carsten
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>This context is a map containing key value pairs, it contains some "global" information (paths etc.) and e.g. the object model.
>So even if we would move away from avalon we could have this map without breaking compatibility here. That's why I'm against "avalonContext".
>
>
Ok, I understand your point. It's true that Avalon's context is
basically an immutable Map with no means to get the list of entries. But
if we move away from Avalon, it's very likely that this concept of
container context will even not exist.
>We already have cocoon.context, couldn't we make things available from there?
>
>
Mmmh... don't know if it's a good idea, as the Cocoon core currently
doesn't rely on custom attributes in the environment objects (unless I'm
mistaken). This would complexify things a bit, IMO.
In the end, I think that either we add cocoon.avalonContext or we commit
the ContextAccess I proposed to Jeremy (we can also merge it in
ContextHelper). But let's not try to abstract what Avalon provides in a
framework-independent manner as that abstraction may disappear it we
move away from Avalon.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [VOTE] Unrestricting the FOM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
This context is a map containing key value pairs, it contains some
"global" information (paths etc.) and e.g. the object model.
So even if we would move away from avalon we could have this
map without breaking compatibility here.
That's why I'm against "avalonContext".
We already have cocoon.context, couldn't we make things
available from there?
Carsten
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org]
> Sent: Monday, June 14, 2004 2:47 PM
> To: dev@cocoon.apache.org
> Subject: Re: [VOTE] Unrestricting the FOM
>
> Carsten Ziegeler wrote:
>
> >Sylvain Wallez wrote:
> >
> >
> >>- [ ] to remove restrictions on existing objects.
> >>
> >>
> >+1
> >
> >
> >>- [ ] to add cocoon.avalonContext.
> >>
> >>
> >
> >-1 for the name "avalonContext". I think we should avoid
> references to Avalon whereever possible. Otherwise perhaps we
> have to rename it in the future.
> >So, +1 if a different name is used.
> >
> >
>
> Well, how to name it since this *is* the Avalon context? I
> mean if one day we totally move away from Avalon, that object
> will naturally disappear. With some back compatibility
> problems, of course, but there will also be many others in
> many other places in our code.
>
> Or something like "frameworkContext" or "containerContext"?
> Sure, it avoids the Avalon name but IMO doesn't clearly
> indicate what it is about.
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
Re: [VOTE] Unrestricting the FOM
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>- [ ] to remove restrictions on existing objects.
>>
>>
>+1
>
>
>>- [ ] to add cocoon.avalonContext.
>>
>>
>
>-1 for the name "avalonContext". I think we should avoid references to Avalon whereever possible. Otherwise perhaps we have to rename it in the future.
>So, +1 if a different name is used.
>
>
Well, how to name it since this *is* the Avalon context? I mean if one
day we totally move away from Avalon, that object will naturally
disappear. With some back compatibility problems, of course, but there
will also be many others in many other places in our code.
Or something like "frameworkContext" or "containerContext"? Sure, it
avoids the Avalon name but IMO doesn't clearly indicate what it is about.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [VOTE] Unrestricting the FOM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> - [ ] to remove restrictions on existing objects.
+1
> - [ ] to add cocoon.avalonContext.
-1 for the name "avalonContext". I think we should avoid references
to Avalon whereever possible. Otherwise perhaps we have to rename
it in the future.
So, +1 if a different name is used.
Carsten