Igor, Thanks. I did have a look at that early on (so maybe I wasn't thinking Wicket enough to get it). It seemed to me that that didn't really help for things like forms etc that we want to work in Ajax style (partial update etc) and with full page refresh (only JavaScript being onchange for select element).
Our test example for our prototype is a query builder where you can add/remove conditions and part of the form changes if you change what field you are searching. I can't see how to do this without switching between AjaxButton and Button depending on type of browser... Also changing if ListChoice uses the AjaxFormComponentUpdatingBehavior or onSelectionChanged... Wicket seems setup to allow power users to build very intricate Ajax app _OR_ plain HTML not really both at the same time. Sorry if I'm being thick. Think I'm bright enough for your original comment to worry me. Trying to grow out of the sort of geek who always has to rewrite everything ;) igor.vaynberg wrote: > > we already have support for "unobtrusive" ajax via AjaxFallbackLink and > AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it will > be just what you are looking for. > > -igor > > > On 8/31/07, Sam Hough <[EMAIL PROTECTED]> wrote: >> >> >> igor, >> >> I've not been able to get rid of the requirement I've been given to >> support >> an Ajax capable client and old browser with tiny bit of JavaScript. Your >> words seem more true than ever but I can't think of a better way of doing >> it >> than the Swing/AWT style with our own simple objects being proxies to >> different Wicket components. e.g. AjaxButton or Button... What would you >> do >> if you were me? Before I try and make our prototype ship shape ;) >> >> Today your words seemed even more true as I'm tempted to digress from the >> Wicket style and use event handler style: someButton.add(new >> EventHandler... >> So as you say writing our own framework. >> >> >> igor.vaynberg wrote: >> > >> > the ui layer is generally not portable. if you start building your own >> > abstraction to make it portable you will end up with a pretty big mess >> > because you will be working against whatever framework you are using >> and >> > eventually that abstraction will turn into a framework itself. >> > >> > -igor >> > >> > >> > On 8/24/07, Sam Hough <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> Many thanks Igor, that sounds like a very pragmatic approach. I was >> >> thinking >> >> about all sorts of horrible kludges like re-rendering the whole page >> and >> >> seeing how elements changed or hooking into the serialisation. >> >> >> >> Taken away another reason to do my over complicated solution ;) Am I >> >> worrying over nothing that developers might get carried away using >> vast >> >> number of components and fiddling with attributes that will make the >> >> application difficult to test and maybe one day port? Restricting the >> set >> >> of >> >> components can presumably end up with a more consistent UI... >> >> >> >> Anyway, thanks for all your time and sage advice. >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 >> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
