You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2003/09/25 23:21:25 UTC
Remove FormHandler? (was Re: cvs commit: cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples
BindingWoodyApple.java)
Carsten,
Fixed, and committing...
Motivation: Thx to the woody-event changes from Sylvain this sample can
in fact remove all references to the (now old)FormHandler.
on a related matter:
I really would remove the class alltogether as it would trigger
additional compile errors maybe in early adopters' apps resulting in
people changing to the new way of event-handling sooner rather then
later. (already pre 2.1.2 that is :-))
Or if this triggers an avalance of "Hey this and that isn't working any
more" -mails then it might even yield the use-case(s) (see
code-comments) we are looking for ;-)
regards,
-marc=
cziegeler@apache.org wrote:
> cziegeler 2003/09/24 15:21:07
>
> Modified: src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples
> BindingWoodyApple.java
> Log:
> Fix compilation
>
> Revision Changes Path
> 1.4 +2 -1 cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples/BindingWoodyApple.java
>
> Index: BindingWoodyApple.java
> ===================================================================
> RCS file: /home/cvs/cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples/BindingWoodyApple.java,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- BindingWoodyApple.java 24 Sep 2003 21:26:51 -0000 1.3
> +++ BindingWoodyApple.java 24 Sep 2003 22:21:07 -0000 1.4
> @@ -148,7 +148,8 @@
> formSource = resolver.resolveURI(formURI);
> this.form = formManager.createForm(formSource);
> formHandler = (FormHandler) this.makeInstance(formHandlerClassName);
> - formHandler.setup(this.form);
> + // FIX THIS
> + // formHandler.setup(this.form);
> this.form.setFormHandler(formHandler);
>
> bindSource = resolver.resolveURI(bindURI);
>
>
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Woody Event handlers are isolated !
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Sylvain Wallez wrote:
>>
>><snip/>
>>
>>
>>>For JavaScript listeners, the I'd like to provide the "cocoon" object, with the exception that sendPage() and sendPageAndWait() won't be available. And if the form is called by a flowscript, also make the global variables (i.e. the session scope) available.
>>>
>>>
>>Done, even if committed a few minutes after the code freeze announcement :-/
>>
>>
>Yep, and the eyes of the release manager did notice this!
>
Please, please, Mr Beloved Release Manager, don't hit me ;-D
>So, I suggest that this costs you a round of free beer for the release manager at the GT ;) He really likes Belgium beer!
>
>(don't take this seriously, it's a joke. Although...)
>
Well, I already owe you so much beers since last year that you really
will have it ;-)
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
RE: Woody Event handlers are isolated !
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Sylvain Wallez wrote:
>
> <snip/>
>
> > For JavaScript listeners, the I'd like to provide the "cocoon" object,
> > with the exception that sendPage() and sendPageAndWait() won't be
> > available. And if the form is called by a flowscript, also make the
> > global variables (i.e. the session scope) available.
>
>
> Done, even if committed a few minutes after the code freeze
> announcement :-/
>
Yep, and the eyes of the release manager did notice this! So, I suggest
that this costs you a round of free beer for the release manager at the
GT ;) He really likes Belgium beer!
(don't take this seriously, it's a joke. Although...)
Carsten
Re: Woody Event handlers are isolated !
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
<snip/>
> For JavaScript listeners, the I'd like to provide the "cocoon" object,
> with the exception that sendPage() and sendPageAndWait() won't be
> available. And if the form is called by a flowscript, also make the
> global variables (i.e. the session scope) available.
Done, even if committed a few minutes after the code freeze announcement :-/
For Java listeners as Avalon components, you'll have to wait for the
2.1.2 to be out.
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
Re: Woody Event handlers are isolated !
Posted by Ramy Mamdouh <ra...@imkenberg.net>.
Hello Sylvain,
Sylvain Wallez wrote:
> Ramy Mamdouh wrote:
>
>> Hello,
>>
>> The new woody event handling looks really promising, but I'm concerned
>> with the listeners being isolated from the rest of the application.
>>
>> Is there any way we can provide the listeners with, say, the
>> ServiceManager and some logger (the avalon life cycle stuff maybe)?
>>
>> or maybe with the 'cocoon' object that's available from the javascript?
>>
>> What do you think about this issue?
>
>
>
> That's exactly what I plan to do now ;-)
>
> I want to introduce in Woody the pattern I used in the TreeProcessor :
> each widget definition and each listener will go through the Avalon
> lifecycle.
That's exactly what I dreamed to see, and it will be really cool :-)
Thanks a lot for your great efforts.
>
> For JavaScript listeners, the I'd like to provide the "cocoon" object,
> with the exception that sendPage() and sendPageAndWait() won't be
> available. And if the form is called by a flowscript, also make the
> global variables (i.e. the session scope) available.
>
> Sylvain
>
--
Ramy Mamdouh Kamel
ramy@imkenberg.net
Re: Woody Event handlers are isolated !
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ramy Mamdouh wrote:
> Hello,
>
> The new woody event handling looks really promising, but I'm concerned
> with the listeners being isolated from the rest of the application.
>
> Is there any way we can provide the listeners with, say, the
> ServiceManager and some logger (the avalon life cycle stuff maybe)?
>
> or maybe with the 'cocoon' object that's available from the javascript?
>
> What do you think about this issue?
That's exactly what I plan to do now ;-)
I want to introduce in Woody the pattern I used in the TreeProcessor :
each widget definition and each listener will go through the Avalon
lifecycle.
For JavaScript listeners, the I'd like to provide the "cocoon" object,
with the exception that sendPage() and sendPageAndWait() won't be
available. And if the form is called by a flowscript, also make the
global variables (i.e. the session scope) available.
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
Woody Event handlers are isolated ! (was: Re: Remove FormHandler?
)
Posted by Ramy Mamdouh <ra...@imkenberg.net>.
Hello,
The new woody event handling looks really promising, but I'm concerned
with the listeners being isolated from the rest of the application.
Is there any way we can provide the listeners with, say, the
ServiceManager and some logger (the avalon life cycle stuff maybe)?
or maybe with the 'cocoon' object that's available from the javascript?
What do you think about this issue?
Thanks in advance.
Ramy
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>> Carsten,
>>
>> Fixed, and committing...
>>
>> Motivation: Thx to the woody-event changes from Sylvain this sample
>> can in fact remove all references to the (now old)FormHandler.
>
>
>
> Yep. +1 !!
>
>> on a related matter:
>> I really would remove the class alltogether as it would trigger
>> additional compile errors maybe in early adopters' apps resulting in
>> people changing to the new way of event-handling sooner rather then
>> later. (already pre 2.1.2 that is :-))
>
>
>
> I left FormHandler for the sake of compatibility, but I agree that it
> should be removed ASAP if we agree that this is no more the way to go.
>
>> Or if this triggers an avalance of "Hey this and that isn't working
>> any more" -mails then it might even yield the use-case(s) (see
>> code-comments) we are looking for ;-)
>
>
>
> Do you mean knowing what people use FormHandler for, giving us some
> input to define some new reactive widgets such as <repeater-action> ?
>
> Sylvain
>
--
Ramy Mamdouh Kamel
ramy@imkenberg.net
Re: Remove FormHandler? (was Re: cvs commit: cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/samples
BindingWoodyApple.java)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Marc Portier wrote:
> Carsten,
>
> Fixed, and committing...
>
> Motivation: Thx to the woody-event changes from Sylvain this sample
> can in fact remove all references to the (now old)FormHandler.
Yep. +1 !!
> on a related matter:
> I really would remove the class alltogether as it would trigger
> additional compile errors maybe in early adopters' apps resulting in
> people changing to the new way of event-handling sooner rather then
> later. (already pre 2.1.2 that is :-))
I left FormHandler for the sake of compatibility, but I agree that it
should be removed ASAP if we agree that this is no more the way to go.
> Or if this triggers an avalance of "Hey this and that isn't working
> any more" -mails then it might even yield the use-case(s) (see
> code-comments) we are looking for ;-)
Do you mean knowing what people use FormHandler for, giving us some
input to define some new reactive widgets such as <repeater-action> ?
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