Yes, it makes sense. My first attempt at this was actually listening for the "onclick" event on a submit button but it has the same effect.
Now my question is: what would be the solution in this case? (i.e. if I should log a JIRA issue/bug, what would it contain?) When capturing the "onsubmit" event on the form, it must be submitted, right? Would there be a way to stop this or would it require a completely different mechanism? Again, I would suggest the "updateComponents" parameter as a solution since it has always worked so well on Tacos. -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 2 de agosto de 2006 19:39 To: Tapestry users Subject: Re: Ajax form question about Tapestry 4.1 Sounds like a possible bug. It makes sense though now.. All the @EventListener would do in this instance is bind to the event happening, not interfere with "what" happens. Your form submitting probably just blew away any chance of having the ajax stuff completing :) On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote: > > > I've been trying to avoid adding too many new parameters (like > > updateComponents) all over the place before I felt like I had found a > good > > way to do this without code duplication. > > I'm all for reducing the number of parameters as long as there some other > way to do the same thing. It's just that I couldn't get it to work in any > other way. > But I also think the updateComponents parameter could be very useful. In > some cases it could be a welcome replacement to writing a listener method > with an EventListener annotation. > > > As for Forms, you could very easily use @EventListener, targeting a form > + > > event of "onsubmit" to get the same result. (Use ResponseBuilder to > update > > whatever components you want, possibly event the whole form so you see > the > > server side rendered validators.) > > Yes, I tried exactly that: > > @EventListener(targets="form", events="onsubmit") > public void myListener(IRequestCycle cycle) { > ... do something ... > cycle.getResponseBuilder().updateComponent("x"); > } > > But when I click on a submit button, the entire page is still reloaded. I > tried it with my submit button's action/listener parameter being the same > listener as the EventListener annotation. > From what I could understand from the tests I made, the component "x" (as > in > the above example) gets rendered twice, once for the ajax update and once > more for the page reload. > I think I'm failing somehow to tell the framework that this should be an > ajax-only request. Since you said it should work, it could be something > that > I'm doing wrong, or could be a bug that shows under certain conditions. > Any ideas? > > > Cheers > Denis Souza > > -----Original Message----- > From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] > Sent: quarta-feira, 2 de agosto de 2006 18:24 > To: Tapestry users > Subject: Re: Ajax form question about Tapestry 4.1 > > I've been trying to avoid adding too many new parameters (like > updateComponents) all over the place before I felt like I had found a good > way to do this without code duplication. > > It's probably fair that I at least add them to form/form button based > components though. > > As for Forms, you could very easily use @EventListener, targeting a form + > event of "onsubmit" to get the same result. (Use ResponseBuilder to update > whatever components you want, possibly event the whole form so you see the > server side rendered validators.) > > Although, if all you care about is the UI mechanism employed to decorate > form fields then you might find doing it on the client side to be more > efficient. > > Perhaps I should allow an easier to use(understand?) method of decorating > form fields on the client side similar to (if not the same? will have to > think about this) the existing ValidationDelegate? > > If you wanted to re-produce the "look" the server gives you could fairly > easily take the javascript reference found here - > http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html - > and > handle the UI part anyway you like. > > If you have a Border component or similar the perfect thing to do might be > to define a javascript block like so to override the default Tapestry > client > side decorating logic (not validation logic, you have to override a > different function for that): > > <script type="text/javascript"> > tapestry.form.validation.handleMissingField=function(field, profile) { > /// Do whatever you want, the default just applies a CSS class name to > the field node. You could just as easily wrap the field with a span or > font > element and give it red **'s if you like > } > </script> > > Can you guys log some of the things you've mentioned into JIRA so that I > don't forget? I probably won't be able to spend enough time on them > (design > wise) until this weekend to implement it correctly, but may forget if no > JIRA issue has been created. > > On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote: > > > > Yeah I was sort of wondering the same thing, and in particular, how do > > I get validation messages to render via ajax -- that is, i wat the > > form to go through the normal validation routine and I dont want to > > enable client side validation. I actually kind of like the red stars > > and custom decorators the validation classes afford you... > > > > i remember in tacos there was an example of employing the validators > > (ie, led red asterisks appeared via ajax), is this possible in > > tapestry 4.1 without some weird kludge? > > > > I read in the docs that the default is to disable validation when > > using submitForm -- since most of the use cases would make incurring > > the validation lifecycle cumbersome to the user. Thats the default, > > which implies it can be toggled... can it, and if so, how? ;-) > > > > Thanks, > > > > Josh > > > > On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote: > > > Hi, I was looking at the new Tapestry 4.1 ajax features. > > > EventListener/ResponseBuilder are really nice! Besides the new > > annotations I > > > noticed some components (such as DirectLink) already have the Tacos > ajax > > > functionality built in which allows you to update a certain part of > the > > page > > > ("updateComponents" parameter), however I didn't find the same > > functionality > > > for the forms and submit buttons. > > > > > > > > > > > > I tried using an EventListener/ResponseBuilder combination (listening > > for > > > onClick and onSubmit) to try and get the same result but whenever I > > click on > > > a submit button the form is submitted the traditional way, the entire > > page > > > is reloaded. I'm guessing this could be solved by replacing the submit > > > buttons with regular links and having the form submitted on the > > > EventListener, but it just doesn't feel right not to use submit > buttons > > > where they are needed. > > > > > > > > > > > > Is there a new way to do this (maybe using the annotations) or is the > > ajax > > > form submit functionality just not implemented yet? > > > > > > > > > > > > Cheers > > > > > > Denis Souza > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
