You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2004/04/27 11:24:53 UTC
cforms: events on widget instances
I've just added the instance based event listeners. You can both add and
remove them.
Following table summarizes the current event situation, see below for
more info.
valuechanged action
field Y N/A
multivaluefield (*) N/A
booleanfield Y N/A
repeater N/A N/A
output N/A N/A
submit N/A Y
action N/A Y
repeater-action N/A Y
row-action N/A Y
aggregatefield (**) N/A
upload N/A N/A
messages N/A N/A
N/A means not applicable
For those events where Y (yes) is mentioned, they are supported both in
the definition and the instance.
And then the special cases:
(*) multivaluefield: the builder happily builds the listeners, but
multivaluefield seems to nowhere create events. So I haven't added
instance-based event listeners on that widget either. -> solution I see
is to add full support for value changed events to this widget.
(**) aggregatefield: the definition and definition builder don't support
value changed events, and events are hence also nowhere created, but
since the instance class extends from Field it automatically has the
possibility to add instance-level event listeners (but they won't ever
be called) -> solution: unsure. Is it possible/meaningful to support
value changed listeners on this widget? Volunteers?
- o -
And now the practical side: example usage in flowscript:
form.getWidget("test").addActionListener(newActionListener(function(event) {
print("hi there");
}));
where the newActionListener function is as follows:
function newActionListener(listenerFunction) {
var listener = {actionPerformed: listenerFunction };
var adapter = new
JavaAdapter(Packages.org.apache.cocoon.forms.event.ActionListener,
listener);
return adapter;
}
Question: do we add these newActionListener and newValueChangedListener
functions to the (javascript) form object, or as separate functions next
to it?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: cforms: events on widget instances
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2004-04-30 at 16:10, Vadim Gritsenko wrote:
> Bruno Dumon wrote:
>
> >On Fri, 2004-04-30 at 14:30, Vadim Gritsenko wrote:
> >
> >
> >>Sylvain Wallez wrote:
> >>
> >>
> >>
> >>>Bruno Dumon wrote:
> >>>
> >>>
> >>...
> >>
> >>
> >>
> >>>>And now the practical side: example usage in flowscript:
> >>>>
> >>>>form.getWidget("test").addActionListener(newActionListener(function(event)
> >>>>{
> >>>> print("hi there");
> >>>>}));
> >>>>
> >>>>where the newActionListener function is as follows:
> >>>>
> >>>>function newActionListener(listenerFunction) {
> >>>> var listener = {actionPerformed: listenerFunction };
> >>>> var adapter = new
> >>>>JavaAdapter(Packages.org.apache.cocoon.forms.event.ActionListener,
> >>>>listener);
> >>>> return adapter;
> >>>>}
> >>>>
> >>>>Question: do we add these newActionListener and newValueChangedListener
> >>>>functions to the (javascript) form object, or as separate functions next
> >>>>to it?
> >>>>
> >>>>
> >>>>
> >>>It could also be an additional method of ScriptableWidget, which would
> >>>take care of the adaptation.
> >>>
> >>>
> >>Agreed. And syntax should become then simply:
> >>
> >>form.getWidget("test").addActionListener(function(event) {
> >> print("hi there");
> >>});
> >>
> >>
> >
> >Saw my message about the v3 api?
> >
> >
>
> Saw but have not read yet - just got cable internet setup yesterday ;-)
>
>
> >there I've implemented it as:
> >
> >form.model.test.onActivate = function() { print("hi there"); }
> >
> >which is still more readable and (I think) flexible enough.
> >
>
> Does it support more than one listener? Not that I need it right away,
> but addActionListener implies more than one listener, where "onActivate
> =" implies just one (setter semantic).
yep that's right, it only supports one. I think that for the flowscript
integration this is good enough, and it makes it somewhat simpler to
read and understand.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: cforms: events on widget instances
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Bruno Dumon wrote:
>On Fri, 2004-04-30 at 14:30, Vadim Gritsenko wrote:
>
>
>>Sylvain Wallez wrote:
>>
>>
>>
>>>Bruno Dumon wrote:
>>>
>>>
>>...
>>
>>
>>
>>>>And now the practical side: example usage in flowscript:
>>>>
>>>>form.getWidget("test").addActionListener(newActionListener(function(event)
>>>>{
>>>> print("hi there");
>>>>}));
>>>>
>>>>where the newActionListener function is as follows:
>>>>
>>>>function newActionListener(listenerFunction) {
>>>> var listener = {actionPerformed: listenerFunction };
>>>> var adapter = new
>>>>JavaAdapter(Packages.org.apache.cocoon.forms.event.ActionListener,
>>>>listener);
>>>> return adapter;
>>>>}
>>>>
>>>>Question: do we add these newActionListener and newValueChangedListener
>>>>functions to the (javascript) form object, or as separate functions next
>>>>to it?
>>>>
>>>>
>>>>
>>>It could also be an additional method of ScriptableWidget, which would
>>>take care of the adaptation.
>>>
>>>
>>Agreed. And syntax should become then simply:
>>
>>form.getWidget("test").addActionListener(function(event) {
>> print("hi there");
>>});
>>
>>
>
>Saw my message about the v3 api?
>
>
Saw but have not read yet - just got cable internet setup yesterday ;-)
>there I've implemented it as:
>
>form.model.test.onActivate = function() { print("hi there"); }
>
>which is still more readable and (I think) flexible enough.
>
Does it support more than one listener? Not that I need it right away,
but addActionListener implies more than one listener, where "onActivate
=" implies just one (setter semantic).
Vadim
Re: cforms: events on widget instances
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2004-04-30 at 14:30, Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
> > Bruno Dumon wrote:
>
> ...
>
> >> And now the practical side: example usage in flowscript:
> >>
> >> form.getWidget("test").addActionListener(newActionListener(function(event)
> >> {
> >> print("hi there");
> >> }));
> >>
> >> where the newActionListener function is as follows:
> >>
> >> function newActionListener(listenerFunction) {
> >> var listener = {actionPerformed: listenerFunction };
> >> var adapter = new
> >> JavaAdapter(Packages.org.apache.cocoon.forms.event.ActionListener,
> >> listener);
> >> return adapter;
> >> }
> >>
> >> Question: do we add these newActionListener and newValueChangedListener
> >> functions to the (javascript) form object, or as separate functions next
> >> to it?
> >>
> >
> > It could also be an additional method of ScriptableWidget, which would
> > take care of the adaptation.
>
>
> Agreed. And syntax should become then simply:
>
> form.getWidget("test").addActionListener(function(event) {
> print("hi there");
> });
Saw my message about the v3 api?
there I've implemented it as:
form.model.test.onActivate = function() { print("hi there"); }
which is still more readable and (I think) flexible enough.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: cforms: events on widget instances
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Bruno Dumon wrote:
...
>> And now the practical side: example usage in flowscript:
>>
>> form.getWidget("test").addActionListener(newActionListener(function(event)
>> {
>> print("hi there");
>> }));
>>
>> where the newActionListener function is as follows:
>>
>> function newActionListener(listenerFunction) {
>> var listener = {actionPerformed: listenerFunction };
>> var adapter = new
>> JavaAdapter(Packages.org.apache.cocoon.forms.event.ActionListener,
>> listener);
>> return adapter;
>> }
>>
>> Question: do we add these newActionListener and newValueChangedListener
>> functions to the (javascript) form object, or as separate functions next
>> to it?
>>
>
> It could also be an additional method of ScriptableWidget, which would
> take care of the adaptation.
Agreed. And syntax should become then simply:
form.getWidget("test").addActionListener(function(event) {
print("hi there");
});
Vadim
Re: cforms: events on widget instances
Posted by Sylvain Wallez <sy...@apache.org>.
Bruno Dumon wrote:
>I've just added the instance based event listeners. You can both add and
>remove them.
>
>Following table summarizes the current event situation, see below for
>more info.
>
> valuechanged action
>field Y N/A
>multivaluefield (*) N/A
>booleanfield Y N/A
>repeater N/A N/A
>output N/A N/A
>submit N/A Y
>action N/A Y
>repeater-action N/A Y
>row-action N/A Y
>aggregatefield (**) N/A
>upload N/A N/A
>messages N/A N/A
>
>N/A means not applicable
>
>For those events where Y (yes) is mentioned, they are supported both in
>the definition and the instance.
>
>
I'd like to add "action" on every widget where a @submit-on-change makes
sense (field, booleanfield, multivaluefield, upload). This would allow
to have some specific event-handling related to the fact that the widget
was activated, regardless if its value changed or not.
>And then the special cases:
>
>(*) multivaluefield: the builder happily builds the listeners, but
>multivaluefield seems to nowhere create events. So I haven't added
>instance-based event listeners on that widget either. -> solution I see
>is to add full support for value changed events to this widget.
>
>(**) aggregatefield: the definition and definition builder don't support
>value changed events, and events are hence also nowhere created, but
>since the instance class extends from Field it automatically has the
>possibility to add instance-level event listeners (but they won't ever
>be called) -> solution: unsure. Is it possible/meaningful to support
>value changed listeners on this widget? Volunteers?
>
> - o -
>
>And now the practical side: example usage in flowscript:
>
>form.getWidget("test").addActionListener(newActionListener(function(event) {
> print("hi there");
>}));
>
>where the newActionListener function is as follows:
>
>function newActionListener(listenerFunction) {
> var listener = {actionPerformed: listenerFunction };
> var adapter = new
>JavaAdapter(Packages.org.apache.cocoon.forms.event.ActionListener,
>listener);
> return adapter;
>}
>
>Question: do we add these newActionListener and newValueChangedListener
>functions to the (javascript) form object, or as separate functions next
>to it?
>
>
It could also be an additional method of ScriptableWidget, which would
take care of the adaptation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cforms: events on widget instances
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 27 Apr 2004, at 10:24, Bruno Dumon wrote:
<snip>
> (*) multivaluefield: the builder happily builds the listeners, but
> multivaluefield seems to nowhere create events. So I haven't added
> instance-based event listeners on that widget either. -> solution I see
> is to add full support for value changed events to this widget.
I would love to see value changed events added to multivaluefield.
I was developing a form earlier that was making a (Hibernate-managed)
Bean that had 9 many-to-many relationships (Collections of Beans on the
Bean) where each one was multivaluefield you could use to add and
remove Beans from the Collections.
Currently I have to expensively reset each of these properties each
time the form is submitted, regardless of change.
<snip/>
regards Jeremy