On 9/1/07, Sam Hough <[EMAIL PROTECTED]> wrote: > > > Doh, hadn't seen the AjaxFallbackButton... That definitely puts a dent in > my > current plan.
read my second post in this long thread, i explicitly told you about this stuff as i thought it would fit your usecase well :) * Sending extra HTML to clients that didn't need it (we are based in the UK > and have lots of cutomers in Oz, Africa, Japan...). So the clients that > needed full browser refresh would get even more HTML... huh? if they need a full page refresh they would get more html? what do you mean? * What happens in browsers that half work? e.g. IE5.0 that has JavaScript > enabled but can't do Ajax properly. if js is on we check if it supports ajax. if it doesnt the fallback behavior executes. -igor Guess I can still hide the AjaxTarget stuff via OurButton etc that extends > AjaxFallbackButton, setOutputMarkupId(true) etc..., unify the event > handlers... > > Guess you were right. No fun writing code the same way as everybody else > even if it is simpler, quicker and less buggy ;) > > > igor.vaynberg wrote: > > > > 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] > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12441886 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
