Igor,

We are not really trying to make it portable or our own abstraction. The aim
would be a subset of the non-ajax Wicket API. In my comfortable ignorance it
is a nice way to keep track of dirty components, hide details of
ajax/non-ajax and let our tech lead keep firm control over which bits of
wicket we use.

I'm totally with you that this could turn into a real pain. Container
systems like EJB2, Swing etc suggest it can go horribly wrong.


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#a12317759
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to