wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Vaynberg" <igor.vaynb...@gmail.com>
Subject Re: Component Factory and code against interface
Date Sun, 02 Sep 2007 04:58:19 GMT
On 9/1/07, Sam Hough <sam@redspr.com> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message