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 <[EMAIL PROTECTED]> 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 <[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
--
Julian Wood <[EMAIL PROTECTED]>
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
