yeah, im def not saying that _everything_ will work like that, but it is _possible_ to do it. what we did is already cover the most common things like links and form submit buttons.
so try to get that case working first instead of switching between button and ajaxbutton use ajaxfallbackbutton. what will happen is that your app will work with ajax in a browser, but as soon as you turn javascript off it will work with regular requests. all pretty much transparent. when you get that working the next step will be to crate a ajaxfallbackdropdown that will do ajax onchange notifications where possible, and fallback on regular when not. you can build a layer of these ajaxfallback components for your app. that is probably the way to go. it isnt 100% flexible, but you can work on that later. one step at a time. -igor On 8/31/07, Sam Hough <[EMAIL PROTECTED]> wrote: > > > 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] > >
