On Mon, Jun 1, 2015 at 5:08 PM, Urbani, Edmund <edmund.urb...@lilandit.com> wrote:
> > > On 06/01/2015 03:48 PM, Martin Grigorov wrote: > >> >> On Mon, Jun 1, 2015 at 3:39 PM, Urbani, Edmund < >> edmund.urb...@lilandit.com <mailto:edmund.urb...@lilandit.com>> wrote: >> >> Ah, of course: wicket-datetime. >> >> Thanks, I'll try that - though I was hoping I would not to have to >> work >> directly with its sub-components. >> >> And more out of curiosity: >> Will there be a neater way to do this in Wicket 7 (or perhaps 8)? >> Right >> now AJAX behaviors that can be applied to FormComponentPanels seem >> like a >> good idea to me. ;) >> >> >> No, there is nothing about this in Wicket 7.x. >> I don't think there will be something in 8.x too. We are not big fans of >> auto-magical functionalities. >> We prefer to give you the facilities (like the factory methods, visitors, >> etc.) and let you define your application logic. >> >> What I'd do for your use case is to extend OnChangeAjaxBehavior, override >> its #updateRequestAttributes() with attributes.setChildSelector("input, >> select, textarea") and attributes.getDynamicExtraParameters("return >> collectChildrenFormElementsValues(attrs.c)") and then in onChange() read >> the submitted values and update the form components. >> But you will need Wicket 6.x for all this... >> > > I see. Well, maybe not "auto-magical" in the sense that Wicket takes care > of that, but in the sense that the component-developer has a way to apply a > behavior to a number of sub-components. Right now, I think, that is not > possible by overriding add(..), because the same behavior instance cannot > be assigned to multiple components AFAIK. > Right. You cannot reuse the same *Ajax* behavior for several components. Because it is not clear which server side component should be updated when the Ajax call is made. Non-Ajax behaviors do not have this restriction. > > In my case applying the behavior to the individual fields was only part of > the solution BTW. I did end up making my own version of the DateTimeField > component. Changes to the hour/minutes fields would not cause the model to > get updated, so I had to modify setHours() and setMinutes() and access some > private stuff (so much for the sub-classing approach... :/ ). > Well, there are always uncovered use cases. What you should do now is to improve DateTimeField in a such a way that it is enough to sub-class it and send us a patch or Pull Request. If the improvement is approved then the next version of Wicket will come with it and you will be able to get rid of your copy of this class. Sounds fair, right? > > Kind regards, > Edmund >
