Two motivations for dirty components being sent automatically are:
1) What gets updated may be through quite convoluted logic. e.g. user
changes ownership of a record so delete button gets disabled. I don't really
want to code that the delete button needs resending...
2) I'm probably missing some Wicket magic but as we have the HTML edition
and Ajax edition Id like the onsubmit etc handlers not to see any Ajax
stuff.
At the moment I'm pondering having something like:
AppSpecificPanel extends OurPanelBase. We then have the normal Wicket
implementation with an adapter that does the work for OurPanelBase. The idea
being that:
* New developers are given a simple set of Components approved by our tech
lead and tested.
* New developers can't fiddle with full power of Wicket.
* Bulk of application code is not tied to Wicket.
* At runtime can have different implementations of a particular component
based on the client.
Obviously the huge downside is added complexity and trying to avoid
inventing our own API. I intend to have our own base class for Panel,
Button... etc so that we can be consistent about a variety of things.
Sorry I've rambled a bit.
igor.vaynberg wrote:
>
> On 8/23/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>>
>>
>> Say my onSubmit handler changes three components, as I understand it, I
>> have
>> to hand code feeding those three components to the AjaxRequestTarget.
>> This
>> seems cumbersome and slightly error prone. I think for our application,
>> if
>> the components kept track of changes, I could automate which components
>> are
>> sent back. Guess what I'm asking is if anything that already exists in
>> Wicket keeps track of component changes? Can't imagine it would be easy
>> otherwise without really heavy duty AOP etc...
>
>
> heh, there is nothing that automatically marks components as dirty()
> because
> wicket doesnt know what you do inside your components. wicket is
> unmanaged.
>
> but i dont really understand the issue. you have onclick(ajaxrequesttarget
> t) { dosomething(); t.addcomponent(....) }
>
> so in your case you mean inside dosomething() you do something to x
> components, but you dont know which x components they are?
>
> -igor
>
>
> Thanks again Igor.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > not really sure what you mean when you say marking components as
>> dirty...
>> >
>> > have you seen ajaxfallback* components? those will use ajax when its
>> > there,
>> > and fallback on regular requests when its not. so you dont even need a
>> > factory necessarily.
>> >
>> > -igor
>> >
>> >
>> > On 8/23/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> Thanks Igor,
>> >>
>> >> Because we have to support Ajax and non-Ajax version I was wondering
>> >> about
>> >> hiding details of making components Ajax friendly in the factory. so
>> >> setOutputMarkupId(true) etc and hiding Ajax specific handlers where
>> >> possible. Have you seen anybody automatically marking components as
>> dirty
>> >> so
>> >> they can be sent back via Ajax (Echo like)? I think that would handle
>> 90%
>> >> of
>> >> our Ajax like stuff.
>> >>
>> >> Cheers
>> >>
>> >> Sam
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12290179
>> >> 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#a12296693
>> 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#a12298767
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
