We use only Ajax or non-Ajax components. No fallbacks. I think in the (near) future we don't really need fallbacks. Everything is javascript nowdays. Only mammooths are fallback.
>From that perspective it seems excess to add code to make something nice that is not going to exist for long. Ofcourse the opposite is also true, if we make fallbacks very comfortable and widely supported, people will continue using non-javascript devices longer than necessary. ** Martin 2011/1/5 Pedro Santos <pedros...@gmail.com>: > Not simplifing (not complicating also), but making clear that an specific > parameter is optional, it can prevent some runtime NPE by exposing in a very > clear way at development time that some parameter may be null. > > On Wed, Jan 5, 2011 at 3:53 PM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> How would it simplify actual code? >> >> ** >> Martin >> >> 2011/1/5 Igor Vaynberg <igor.vaynb...@gmail.com>: >> > ive recently ran into a few cases where while implementing >> > ajaxfallbacklink i forgot to test the passed in request target for >> > null, causing NPEs when the app was accessed from browsers where ajax >> > failed for whatever reason. >> > >> > with all this talk of scala recently i figured why not try and >> > translate one of the feature i really like in scala Option/Null/Some >> > to our code base. >> > >> > i came up with a simple value class: >> > https://gist.github.com/c38456ee75fed541c932 >> > >> > and changed the ajaxfallbacklink to use it >> > https://gist.github.com/2f648c7feacacf18fc40 >> > >> > the cascade from this change was pretty impressive, a lot of places in >> > our code support passing a possibly null request target but make no >> > mention of it: >> > https://gist.github.com/d9933e24c21f061c6ac2 >> > >> > so advantages: >> > makes possible null value handling explicit >> > no more checking the javadoc to see if the method supports null as a >> > parameter value or ever returns a null >> > an api break before 1.5 rc1 >> > i think overall makes lives of wicket users easier >> > >> > disadvantages: >> > a bit wordier code >> > an api break just about when we are ready to release 1.5 m4/rc1 >> > whatever we call it >> > >> > yay or nay? obviously if we say yay there are a lot more places in our >> > code that can benefit from this >> > >> > -igor >> > >> > > > > -- > Pedro Henrique Oliveira dos Santos >
