So I can try and cling on to some credibility at work wasn't ajaxfallbackbutton only added in 1.3-beta3? I think we started working with 1.3-beta2. We only switched because my Swing/AWT version needed a method not to be final which changed in beta3...
Even worse is that my tech lead/client/boss sent me an email about AjaxFallback??? need to check work email that it was Link not Button else I will feel even more stupid. I've got over my worry about non-Ajax clients getting a bigger HTML page than they need. Seemed to add insult to injury that the users that get all the html for every server interaction also get lots of stuff they don't need. However it is a minority of our users and they should get a better browser. I don't think MS supports IE5.5 anymore... So I've stopped worrying about that and I take your reassurance about detecting what a browser is capable of. Think I'll still try and keep the auto dirty component tracking. Might be slightly less clean as I can't intercept all calls to Wicket methods as some of them may be final etc... but I don't have an excuse for such a complicated solution anymore. Hope you don't think having OurButton etc that directly extends AjaxFallBackButton etc is too evil!? I can hide the auto dirty component stuff etc there... setOutputMarkupId(true) etc... Anyway, many thanks Igor. Think you have saved me and my client from overly complicated code. igor.vaynberg wrote: > > 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] >> >> > > -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12446696 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
