You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Julian Wood <wo...@ucalgary.ca> on 2007/06/27 01:19:57 UTC
[t4] EventListener question
I have a pretty straight forward paradigm:
- two groups of 3 radio buttons followed by a property selection.
- an async form with no listener whatsoever
- a submit button with an action listener (called saveTime)
The idea is that choosing a radio button narrows down the list in the
property selection.
I chose to add eventlisteners to the onclicks of the radiobuttons,
and update the property selection in response. The eventlisteners
submit the above form, which is why there is no listener set in the
form binding. For simplicity, I'll call one eventListener method
categorySelected.
This form is entirely contained within a Dialog component, which is
reused.
Now, this all works perfectly the first time through - open the
dialog, fill out the form, watch the property selection values
change, submit the form, close the dialog, reset all the fields. Note
that saveTime is not called when you click a radio button - only
categorySelected.
The second time the dialog is opened, the eventlisteners behave
slightly differently. This time, when you click a radio button, the
form is submitted, categorySelected is invoked _and_ saveTime is
called (which is a problem). The primary difference between the two
posts (at the request level) is the inclusion of the name of said
button, which I believe is how Tapestry determines what listener to
call (ie if &addTimeEventButton=Save%20Time is included, then
saveTime is called - correct me if I'm wrong).
So I'm wondering why the eventlisteners call saveTime (some of the
time), if there is a way to prevent that, or if there is a better way
to approach this problem all together (is an async form with no
listener at all okay?). I know there are a bunch of workarounds, but
I'm looking for that clean solution.
Thanks,
J
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [t4] EventListener question
Posted by Julian Wood <wo...@ucalgary.ca>.
I've made a sample application, as simply as I could, to show the
problem. I've put it on my blog if anyone is interested in looking.
http://jwoodchip.blogspot.com/2007/06/event-listener-oddities.html
Thanks,
J
On 26-Jun-07, at 10:45 PM, Marcus Schulte wrote:
> That should really work. I'm using something very similar (checkbox
> instead
> of radiobutton). If you post some code, I can look for differences.
>
>
> 2007/6/27, Julian Wood <wo...@ucalgary.ca>:
>>
>> I have a pretty straight forward paradigm:
>>
>> - two groups of 3 radio buttons followed by a property selection.
>> - an async form with no listener whatsoever
>> - a submit button with an action listener (called saveTime)
>>
>> The idea is that choosing a radio button narrows down the list in the
>> property selection.
>>
>> I chose to add eventlisteners to the onclicks of the radiobuttons,
>> and update the property selection in response. The eventlisteners
>> submit the above form, which is why there is no listener set in the
>> form binding. For simplicity, I'll call one eventListener method
>> categorySelected.
>>
>> This form is entirely contained within a Dialog component, which is
>> reused.
>>
>> Now, this all works perfectly the first time through - open the
>> dialog, fill out the form, watch the property selection values
>> change, submit the form, close the dialog, reset all the fields. Note
>> that saveTime is not called when you click a radio button - only
>> categorySelected.
>>
>> The second time the dialog is opened, the eventlisteners behave
>> slightly differently. This time, when you click a radio button, the
>> form is submitted, categorySelected is invoked _and_ saveTime is
>> called (which is a problem). The primary difference between the two
>> posts (at the request level) is the inclusion of the name of said
>> button, which I believe is how Tapestry determines what listener to
>> call (ie if &addTimeEventButton=Save%20Time is included, then
>> saveTime is called - correct me if I'm wrong).
>>
>> So I'm wondering why the eventlisteners call saveTime (some of the
>> time), if there is a way to prevent that, or if there is a better way
>> to approach this problem all together (is an async form with no
>> listener at all okay?). I know there are a bunch of workarounds, but
>> I'm looking for that clean solution.
>>
>> Thanks,
>>
>> J
>>
>> --
>> Julian Wood <wo...@ucalgary.ca>
>>
>> Software Engineer
>> Teaching & Learning Centre
>> University of Calgary
>>
>> http://tlc.ucalgary.ca
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Marcus Schulte
> http://marcus-schulte.blogspot.com
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
Re: [t4] EventListener question
Posted by Marcus Schulte <et...@googlemail.com>.
That should really work. I'm using something very similar (checkbox instead
of radiobutton). If you post some code, I can look for differences.
2007/6/27, Julian Wood <wo...@ucalgary.ca>:
>
> I have a pretty straight forward paradigm:
>
> - two groups of 3 radio buttons followed by a property selection.
> - an async form with no listener whatsoever
> - a submit button with an action listener (called saveTime)
>
> The idea is that choosing a radio button narrows down the list in the
> property selection.
>
> I chose to add eventlisteners to the onclicks of the radiobuttons,
> and update the property selection in response. The eventlisteners
> submit the above form, which is why there is no listener set in the
> form binding. For simplicity, I'll call one eventListener method
> categorySelected.
>
> This form is entirely contained within a Dialog component, which is
> reused.
>
> Now, this all works perfectly the first time through - open the
> dialog, fill out the form, watch the property selection values
> change, submit the form, close the dialog, reset all the fields. Note
> that saveTime is not called when you click a radio button - only
> categorySelected.
>
> The second time the dialog is opened, the eventlisteners behave
> slightly differently. This time, when you click a radio button, the
> form is submitted, categorySelected is invoked _and_ saveTime is
> called (which is a problem). The primary difference between the two
> posts (at the request level) is the inclusion of the name of said
> button, which I believe is how Tapestry determines what listener to
> call (ie if &addTimeEventButton=Save%20Time is included, then
> saveTime is called - correct me if I'm wrong).
>
> So I'm wondering why the eventlisteners call saveTime (some of the
> time), if there is a way to prevent that, or if there is a better way
> to approach this problem all together (is an async form with no
> listener at all okay?). I know there are a bunch of workarounds, but
> I'm looking for that clean solution.
>
> Thanks,
>
> J
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Marcus Schulte
http://marcus-schulte.blogspot.com
Re: [t4] EventListener question
Posted by Jesse Kuhnert <jk...@gmail.com>.
Hmmm I'm not sure completely. If you had an example I can play with more
easily attached to a jira issue I can take a look.
On 6/28/07, Julian Wood <wo...@ucalgary.ca> wrote:
>
> Well I'll look forward to the time when that's implemented! But I'm
> still curious what the problem is with my original approach, as it
> seems to be a different problem. That is, after an initial async
> submission, the eventlistener invokes the listener on the submit
> button when it shouldn't.
>
> In the meantime, for completeness, I''ll mention my workaround to
> distinguish between calls to my listener invoked by the eventlistener
> and calls invoked by the submit button. Maybe there is a better one.
>
> I placed a hidden component in my form, called isSubmission, bound to
> a property of the same name, with an initial value of false. I bound
> dojo.byId('isSubmission').value='true' to the onclick handler of the
> submit button. Now in my listener I can distinguish between the two
> types of invocations and act appropriately. The last piece is to set
> the hidden component value back to false and updateComponent on the
> hidden field.
>
> Curiously, something like this doesn't (but should) work (you need to
> use onclick):
>
> dojo.event.connectOnce(tapestry.form, "submitAsync", function(e) {
> dojo.byId("isSubmission").value='true';
> });
>
> I wonder if that has something to do with the problem.
>
> Thanks,
>
> J
>
> On 27-Jun-07, at 9:34 PM, Jesse Kuhnert wrote:
>
> > Haha look at that. ....I forget that it can bind to any function
> > sometimes.
> > That's neat. :)
> >
> > Yes that was what I was thinking as the "strategy" for doing
> > EventListener
> > connections on this specific type of component. It would need to
> > honor any
> > existing informal onclick attributes and back off to something else
> > but I
> > think I have that logic implemented for the various link components
> > already
> > so just need to refactor it out into something more generic and
> > consumable
> > by eventlistener infrastructure.
> >
> > BTW, you can drop off "validateForm/async" from your EventListener
> > parameters if you wanted to as those are the default values. (and
> > when it
> > works with doing a component target="" for radio groups you'll be
> > able to
> > drop off everything but the event and target)
> >
> > On 6/27/07, Julian Wood <wo...@ucalgary.ca> wrote:
> >>
> >> I used a little trick to get the radiobuttons to send an event, which
> >> I suppose could be the problem. All you need to do is add this
> >> onclick handler to each radio button, and then the tapestry event
> >> listener will respond.
> >>
> >> <div jwcid="stage" id="stageRadioGroup">
> >> <input type="radio" jwcid="@Radio"
> >> value="ognl:@...Stage@PreProduction" onclick="document.getElementById
> >> ('stageRadioGroup').clickRadio(this);"/> Pre
> >> ...
> >> </div>
> >>
> >> @EventListener(events = "clickRadio", elements = "stageRadioGroup",
> >> async = true, submitForm = "addEventForm", validateForm = false)
> >> public void stageSelected(IRequestCycle cycle) {...}
> >>
> >> And yes, the problem occurs without the dialog.
> >>
> >> Thanks,
> >>
> >> J
> >>
> >> On 27-Jun-07, at 1:04 PM, Jesse Kuhnert wrote:
> >>
> >> > EventListener && Radio Groups don't really get along so well. The
> >> > reason
> >> > being that each radio group button must have the same name
> >> > attribute and
> >> > there is no dom equivalent of a select->options wrapper around
> >> them.
> >> >
> >> > It's possible that ~something~ can be done for this but I'm not
> >> > sure of what
> >> > that something should be yet. I could of course probably use my
> >> > RadioGroup
> >> > widget to provide this functionality but that's adding a specific
> >> > javascript dependency on a regular form control. (
> >> > http://trac.dojotoolkit.org/browser/branches/0.4/src/widget/
> >> > RadioGroup.js)
> >> > I think we'll have to address this more directly with some sort of
> >> > special
> >> > handling between EventListener and component groupings like this
> >> but I
> >> > haven't figure it out yet.
> >> >
> >> > As for your problem right now, what happens if you do the same
> >> > exact things
> >> > without the Dialog being involved? Does it still happen then ?
> >> >
> >> > On 6/26/07, Julian Wood <wo...@ucalgary.ca> wrote:
> >> >>
> >> >> I have a pretty straight forward paradigm:
> >> >>
> >> >> - two groups of 3 radio buttons followed by a property selection.
> >> >> - an async form with no listener whatsoever
> >> >> - a submit button with an action listener (called saveTime)
> >> >>
> >> >> The idea is that choosing a radio button narrows down the list
> >> in the
> >> >> property selection.
> >> >>
> >> >> I chose to add eventlisteners to the onclicks of the radiobuttons,
> >> >> and update the property selection in response. The eventlisteners
> >> >> submit the above form, which is why there is no listener set in
> >> the
> >> >> form binding. For simplicity, I'll call one eventListener method
> >> >> categorySelected.
> >> >>
> >> >> This form is entirely contained within a Dialog component,
> >> which is
> >> >> reused.
> >> >>
> >> >> Now, this all works perfectly the first time through - open the
> >> >> dialog, fill out the form, watch the property selection values
> >> >> change, submit the form, close the dialog, reset all the
> >> fields. Note
> >> >> that saveTime is not called when you click a radio button - only
> >> >> categorySelected.
> >> >>
> >> >> The second time the dialog is opened, the eventlisteners behave
> >> >> slightly differently. This time, when you click a radio button,
> >> the
> >> >> form is submitted, categorySelected is invoked _and_ saveTime is
> >> >> called (which is a problem). The primary difference between the
> >> two
> >> >> posts (at the request level) is the inclusion of the name of said
> >> >> button, which I believe is how Tapestry determines what
> >> listener to
> >> >> call (ie if &addTimeEventButton=Save%20Time is included, then
> >> >> saveTime is called - correct me if I'm wrong).
> >> >>
> >> >> So I'm wondering why the eventlisteners call saveTime (some of the
> >> >> time), if there is a way to prevent that, or if there is a
> >> better way
> >> >> to approach this problem all together (is an async form with no
> >> >> listener at all okay?). I know there are a bunch of
> >> workarounds, but
> >> >> I'm looking for that clean solution.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> J
> >> >>
> >> >> --
> >> >> Julian Wood <wo...@ucalgary.ca>
> >> >>
> >> >> Software Engineer
> >> >> Teaching & Learning Centre
> >> >> University of Calgary
> >> >>
> >> >> http://tlc.ucalgary.ca
> >> >>
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Jesse Kuhnert
> >> > Tapestry/Dojo team member/developer
> >> >
> >> > Open source based consulting work centered around
> >> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >>
> >> --
> >> Julian Wood <wo...@ucalgary.ca>
> >>
> >> Software Engineer
> >> Teaching & Learning Centre
> >> University of Calgary
> >>
> >> http://tlc.ucalgary.ca
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: [t4] EventListener question
Posted by Julian Wood <wo...@ucalgary.ca>.
Well I'll look forward to the time when that's implemented! But I'm
still curious what the problem is with my original approach, as it
seems to be a different problem. That is, after an initial async
submission, the eventlistener invokes the listener on the submit
button when it shouldn't.
In the meantime, for completeness, I''ll mention my workaround to
distinguish between calls to my listener invoked by the eventlistener
and calls invoked by the submit button. Maybe there is a better one.
I placed a hidden component in my form, called isSubmission, bound to
a property of the same name, with an initial value of false. I bound
dojo.byId('isSubmission').value='true' to the onclick handler of the
submit button. Now in my listener I can distinguish between the two
types of invocations and act appropriately. The last piece is to set
the hidden component value back to false and updateComponent on the
hidden field.
Curiously, something like this doesn't (but should) work (you need to
use onclick):
dojo.event.connectOnce(tapestry.form, "submitAsync", function(e) {
dojo.byId("isSubmission").value='true';
});
I wonder if that has something to do with the problem.
Thanks,
J
On 27-Jun-07, at 9:34 PM, Jesse Kuhnert wrote:
> Haha look at that. ....I forget that it can bind to any function
> sometimes.
> That's neat. :)
>
> Yes that was what I was thinking as the "strategy" for doing
> EventListener
> connections on this specific type of component. It would need to
> honor any
> existing informal onclick attributes and back off to something else
> but I
> think I have that logic implemented for the various link components
> already
> so just need to refactor it out into something more generic and
> consumable
> by eventlistener infrastructure.
>
> BTW, you can drop off "validateForm/async" from your EventListener
> parameters if you wanted to as those are the default values. (and
> when it
> works with doing a component target="" for radio groups you'll be
> able to
> drop off everything but the event and target)
>
> On 6/27/07, Julian Wood <wo...@ucalgary.ca> wrote:
>>
>> I used a little trick to get the radiobuttons to send an event, which
>> I suppose could be the problem. All you need to do is add this
>> onclick handler to each radio button, and then the tapestry event
>> listener will respond.
>>
>> <div jwcid="stage" id="stageRadioGroup">
>> <input type="radio" jwcid="@Radio"
>> value="ognl:@...Stage@PreProduction" onclick="document.getElementById
>> ('stageRadioGroup').clickRadio(this);"/> Pre
>> ...
>> </div>
>>
>> @EventListener(events = "clickRadio", elements = "stageRadioGroup",
>> async = true, submitForm = "addEventForm", validateForm = false)
>> public void stageSelected(IRequestCycle cycle) {...}
>>
>> And yes, the problem occurs without the dialog.
>>
>> Thanks,
>>
>> J
>>
>> On 27-Jun-07, at 1:04 PM, Jesse Kuhnert wrote:
>>
>> > EventListener && Radio Groups don't really get along so well. The
>> > reason
>> > being that each radio group button must have the same name
>> > attribute and
>> > there is no dom equivalent of a select->options wrapper around
>> them.
>> >
>> > It's possible that ~something~ can be done for this but I'm not
>> > sure of what
>> > that something should be yet. I could of course probably use my
>> > RadioGroup
>> > widget to provide this functionality but that's adding a specific
>> > javascript dependency on a regular form control. (
>> > http://trac.dojotoolkit.org/browser/branches/0.4/src/widget/
>> > RadioGroup.js)
>> > I think we'll have to address this more directly with some sort of
>> > special
>> > handling between EventListener and component groupings like this
>> but I
>> > haven't figure it out yet.
>> >
>> > As for your problem right now, what happens if you do the same
>> > exact things
>> > without the Dialog being involved? Does it still happen then ?
>> >
>> > On 6/26/07, Julian Wood <wo...@ucalgary.ca> wrote:
>> >>
>> >> I have a pretty straight forward paradigm:
>> >>
>> >> - two groups of 3 radio buttons followed by a property selection.
>> >> - an async form with no listener whatsoever
>> >> - a submit button with an action listener (called saveTime)
>> >>
>> >> The idea is that choosing a radio button narrows down the list
>> in the
>> >> property selection.
>> >>
>> >> I chose to add eventlisteners to the onclicks of the radiobuttons,
>> >> and update the property selection in response. The eventlisteners
>> >> submit the above form, which is why there is no listener set in
>> the
>> >> form binding. For simplicity, I'll call one eventListener method
>> >> categorySelected.
>> >>
>> >> This form is entirely contained within a Dialog component,
>> which is
>> >> reused.
>> >>
>> >> Now, this all works perfectly the first time through - open the
>> >> dialog, fill out the form, watch the property selection values
>> >> change, submit the form, close the dialog, reset all the
>> fields. Note
>> >> that saveTime is not called when you click a radio button - only
>> >> categorySelected.
>> >>
>> >> The second time the dialog is opened, the eventlisteners behave
>> >> slightly differently. This time, when you click a radio button,
>> the
>> >> form is submitted, categorySelected is invoked _and_ saveTime is
>> >> called (which is a problem). The primary difference between the
>> two
>> >> posts (at the request level) is the inclusion of the name of said
>> >> button, which I believe is how Tapestry determines what
>> listener to
>> >> call (ie if &addTimeEventButton=Save%20Time is included, then
>> >> saveTime is called - correct me if I'm wrong).
>> >>
>> >> So I'm wondering why the eventlisteners call saveTime (some of the
>> >> time), if there is a way to prevent that, or if there is a
>> better way
>> >> to approach this problem all together (is an async form with no
>> >> listener at all okay?). I know there are a bunch of
>> workarounds, but
>> >> I'm looking for that clean solution.
>> >>
>> >> Thanks,
>> >>
>> >> J
>> >>
>> >> --
>> >> Julian Wood <wo...@ucalgary.ca>
>> >>
>> >> Software Engineer
>> >> Teaching & Learning Centre
>> >> University of Calgary
>> >>
>> >> http://tlc.ucalgary.ca
>> >>
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Jesse Kuhnert
>> > Tapestry/Dojo team member/developer
>> >
>> > Open source based consulting work centered around
>> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>>
>> --
>> Julian Wood <wo...@ucalgary.ca>
>>
>> Software Engineer
>> Teaching & Learning Centre
>> University of Calgary
>>
>> http://tlc.ucalgary.ca
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
Re: [t4] EventListener question
Posted by Jesse Kuhnert <jk...@gmail.com>.
Haha look at that. ....I forget that it can bind to any function sometimes.
That's neat. :)
Yes that was what I was thinking as the "strategy" for doing EventListener
connections on this specific type of component. It would need to honor any
existing informal onclick attributes and back off to something else but I
think I have that logic implemented for the various link components already
so just need to refactor it out into something more generic and consumable
by eventlistener infrastructure.
BTW, you can drop off "validateForm/async" from your EventListener
parameters if you wanted to as those are the default values. (and when it
works with doing a component target="" for radio groups you'll be able to
drop off everything but the event and target)
On 6/27/07, Julian Wood <wo...@ucalgary.ca> wrote:
>
> I used a little trick to get the radiobuttons to send an event, which
> I suppose could be the problem. All you need to do is add this
> onclick handler to each radio button, and then the tapestry event
> listener will respond.
>
> <div jwcid="stage" id="stageRadioGroup">
> <input type="radio" jwcid="@Radio"
> value="ognl:@...Stage@PreProduction" onclick="document.getElementById
> ('stageRadioGroup').clickRadio(this);"/> Pre
> ...
> </div>
>
> @EventListener(events = "clickRadio", elements = "stageRadioGroup",
> async = true, submitForm = "addEventForm", validateForm = false)
> public void stageSelected(IRequestCycle cycle) {...}
>
> And yes, the problem occurs without the dialog.
>
> Thanks,
>
> J
>
> On 27-Jun-07, at 1:04 PM, Jesse Kuhnert wrote:
>
> > EventListener && Radio Groups don't really get along so well. The
> > reason
> > being that each radio group button must have the same name
> > attribute and
> > there is no dom equivalent of a select->options wrapper around them.
> >
> > It's possible that ~something~ can be done for this but I'm not
> > sure of what
> > that something should be yet. I could of course probably use my
> > RadioGroup
> > widget to provide this functionality but that's adding a specific
> > javascript dependency on a regular form control. (
> > http://trac.dojotoolkit.org/browser/branches/0.4/src/widget/
> > RadioGroup.js)
> > I think we'll have to address this more directly with some sort of
> > special
> > handling between EventListener and component groupings like this but I
> > haven't figure it out yet.
> >
> > As for your problem right now, what happens if you do the same
> > exact things
> > without the Dialog being involved? Does it still happen then ?
> >
> > On 6/26/07, Julian Wood <wo...@ucalgary.ca> wrote:
> >>
> >> I have a pretty straight forward paradigm:
> >>
> >> - two groups of 3 radio buttons followed by a property selection.
> >> - an async form with no listener whatsoever
> >> - a submit button with an action listener (called saveTime)
> >>
> >> The idea is that choosing a radio button narrows down the list in the
> >> property selection.
> >>
> >> I chose to add eventlisteners to the onclicks of the radiobuttons,
> >> and update the property selection in response. The eventlisteners
> >> submit the above form, which is why there is no listener set in the
> >> form binding. For simplicity, I'll call one eventListener method
> >> categorySelected.
> >>
> >> This form is entirely contained within a Dialog component, which is
> >> reused.
> >>
> >> Now, this all works perfectly the first time through - open the
> >> dialog, fill out the form, watch the property selection values
> >> change, submit the form, close the dialog, reset all the fields. Note
> >> that saveTime is not called when you click a radio button - only
> >> categorySelected.
> >>
> >> The second time the dialog is opened, the eventlisteners behave
> >> slightly differently. This time, when you click a radio button, the
> >> form is submitted, categorySelected is invoked _and_ saveTime is
> >> called (which is a problem). The primary difference between the two
> >> posts (at the request level) is the inclusion of the name of said
> >> button, which I believe is how Tapestry determines what listener to
> >> call (ie if &addTimeEventButton=Save%20Time is included, then
> >> saveTime is called - correct me if I'm wrong).
> >>
> >> So I'm wondering why the eventlisteners call saveTime (some of the
> >> time), if there is a way to prevent that, or if there is a better way
> >> to approach this problem all together (is an async form with no
> >> listener at all okay?). I know there are a bunch of workarounds, but
> >> I'm looking for that clean solution.
> >>
> >> Thanks,
> >>
> >> J
> >>
> >> --
> >> Julian Wood <wo...@ucalgary.ca>
> >>
> >> Software Engineer
> >> Teaching & Learning Centre
> >> University of Calgary
> >>
> >> http://tlc.ucalgary.ca
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: [t4] EventListener question
Posted by Julian Wood <wo...@ucalgary.ca>.
I used a little trick to get the radiobuttons to send an event, which
I suppose could be the problem. All you need to do is add this
onclick handler to each radio button, and then the tapestry event
listener will respond.
<div jwcid="stage" id="stageRadioGroup">
<input type="radio" jwcid="@Radio"
value="ognl:@...Stage@PreProduction" onclick="document.getElementById
('stageRadioGroup').clickRadio(this);"/> Pre
...
</div>
@EventListener(events = "clickRadio", elements = "stageRadioGroup",
async = true, submitForm = "addEventForm", validateForm = false)
public void stageSelected(IRequestCycle cycle) {...}
And yes, the problem occurs without the dialog.
Thanks,
J
On 27-Jun-07, at 1:04 PM, Jesse Kuhnert wrote:
> EventListener && Radio Groups don't really get along so well. The
> reason
> being that each radio group button must have the same name
> attribute and
> there is no dom equivalent of a select->options wrapper around them.
>
> It's possible that ~something~ can be done for this but I'm not
> sure of what
> that something should be yet. I could of course probably use my
> RadioGroup
> widget to provide this functionality but that's adding a specific
> javascript dependency on a regular form control. (
> http://trac.dojotoolkit.org/browser/branches/0.4/src/widget/
> RadioGroup.js)
> I think we'll have to address this more directly with some sort of
> special
> handling between EventListener and component groupings like this but I
> haven't figure it out yet.
>
> As for your problem right now, what happens if you do the same
> exact things
> without the Dialog being involved? Does it still happen then ?
>
> On 6/26/07, Julian Wood <wo...@ucalgary.ca> wrote:
>>
>> I have a pretty straight forward paradigm:
>>
>> - two groups of 3 radio buttons followed by a property selection.
>> - an async form with no listener whatsoever
>> - a submit button with an action listener (called saveTime)
>>
>> The idea is that choosing a radio button narrows down the list in the
>> property selection.
>>
>> I chose to add eventlisteners to the onclicks of the radiobuttons,
>> and update the property selection in response. The eventlisteners
>> submit the above form, which is why there is no listener set in the
>> form binding. For simplicity, I'll call one eventListener method
>> categorySelected.
>>
>> This form is entirely contained within a Dialog component, which is
>> reused.
>>
>> Now, this all works perfectly the first time through - open the
>> dialog, fill out the form, watch the property selection values
>> change, submit the form, close the dialog, reset all the fields. Note
>> that saveTime is not called when you click a radio button - only
>> categorySelected.
>>
>> The second time the dialog is opened, the eventlisteners behave
>> slightly differently. This time, when you click a radio button, the
>> form is submitted, categorySelected is invoked _and_ saveTime is
>> called (which is a problem). The primary difference between the two
>> posts (at the request level) is the inclusion of the name of said
>> button, which I believe is how Tapestry determines what listener to
>> call (ie if &addTimeEventButton=Save%20Time is included, then
>> saveTime is called - correct me if I'm wrong).
>>
>> So I'm wondering why the eventlisteners call saveTime (some of the
>> time), if there is a way to prevent that, or if there is a better way
>> to approach this problem all together (is an async form with no
>> listener at all okay?). I know there are a bunch of workarounds, but
>> I'm looking for that clean solution.
>>
>> Thanks,
>>
>> J
>>
>> --
>> Julian Wood <wo...@ucalgary.ca>
>>
>> Software Engineer
>> Teaching & Learning Centre
>> University of Calgary
>>
>> http://tlc.ucalgary.ca
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [t4] EventListener question
Posted by Jesse Kuhnert <jk...@gmail.com>.
EventListener && Radio Groups don't really get along so well. The reason
being that each radio group button must have the same name attribute and
there is no dom equivalent of a select->options wrapper around them.
It's possible that ~something~ can be done for this but I'm not sure of what
that something should be yet. I could of course probably use my RadioGroup
widget to provide this functionality but that's adding a specific
javascript dependency on a regular form control. (
http://trac.dojotoolkit.org/browser/branches/0.4/src/widget/RadioGroup.js)
I think we'll have to address this more directly with some sort of special
handling between EventListener and component groupings like this but I
haven't figure it out yet.
As for your problem right now, what happens if you do the same exact things
without the Dialog being involved? Does it still happen then ?
On 6/26/07, Julian Wood <wo...@ucalgary.ca> wrote:
>
> I have a pretty straight forward paradigm:
>
> - two groups of 3 radio buttons followed by a property selection.
> - an async form with no listener whatsoever
> - a submit button with an action listener (called saveTime)
>
> The idea is that choosing a radio button narrows down the list in the
> property selection.
>
> I chose to add eventlisteners to the onclicks of the radiobuttons,
> and update the property selection in response. The eventlisteners
> submit the above form, which is why there is no listener set in the
> form binding. For simplicity, I'll call one eventListener method
> categorySelected.
>
> This form is entirely contained within a Dialog component, which is
> reused.
>
> Now, this all works perfectly the first time through - open the
> dialog, fill out the form, watch the property selection values
> change, submit the form, close the dialog, reset all the fields. Note
> that saveTime is not called when you click a radio button - only
> categorySelected.
>
> The second time the dialog is opened, the eventlisteners behave
> slightly differently. This time, when you click a radio button, the
> form is submitted, categorySelected is invoked _and_ saveTime is
> called (which is a problem). The primary difference between the two
> posts (at the request level) is the inclusion of the name of said
> button, which I believe is how Tapestry determines what listener to
> call (ie if &addTimeEventButton=Save%20Time is included, then
> saveTime is called - correct me if I'm wrong).
>
> So I'm wondering why the eventlisteners call saveTime (some of the
> time), if there is a way to prevent that, or if there is a better way
> to approach this problem all together (is an async form with no
> listener at all okay?). I know there are a bunch of workarounds, but
> I'm looking for that clean solution.
>
> Thanks,
>
> J
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com