wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Hough <...@redspr.com>
Subject Re: Component Factory and code against interface
Date Sat, 01 Sep 2007 16:43:25 GMT

Doh, hadn't seen the AjaxFallbackButton... That definitely puts a dent in my
current plan. I still like being able to hide/expose as much of the Wicket
API as I like and intercept methods to mark the component dirty but looks
less worth it. As I'm sure you imagined I needed to fiddle with the
resolution of SomeClass.html... 

Guess I'll have to look at the AjaxFallbackXXX code properly. I think my
initial concerns were:
* 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...
* What happens in browsers that half work? e.g. IE5.0 that has JavaScript
enabled but can't do Ajax properly.

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 <sam@redspr.com> 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 <sam@redspr.com> 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 <sam@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message