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] > >
