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 <[EMAIL PROTECTED]> 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:@[EMAIL PROTECTED]" 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>
>> Software Engineer
>> Teaching & Learning Centre
>> University of Calgary
>>
>> http://tlc.ucalgary.ca
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
--
Julian Wood <[EMAIL PROTECTED]>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
