Thanks Johan,
Glad it wasn't a totally silly idea. Any top tips or problems you can share?
Nice that Igor's approach by its very nature avoids sending the same
component more than once. Trees are great ;)
Johan Compagner wrote:
>
> this is how we also do it. Have a changes recorder per component, that
> records changes and when the component renders it sets the dirty flag
> to false
>
> On 8/23/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>> On 8/23/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> > 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...
>>
>>
>> how is any UI framework supposed to know that this happened? the
>> component
>> knows how to render itself based on this record you provide via a model,
>> but
>> it cannot tell it changed. this seems like such a corner case.
>>
>> here is what i would suggest
>>
>> interface IDirtyStateAware { boolean isDirty(); } let your components
>> that
>> know how to check if they are dirty or not implement this. i dont think
>> these should be as granular as a button, but probably bigger components -
>> like a panel that contains the button.
>>
>> then:
>>
>> AjaxFallbackLink link=new AjaxFallbackLink("link") {
>> abstract onClick(); // this is where processing happens
>>
>> onClick(AjaxRequestTarget target) {
>> onClick();
>> getPage().visit(new component.visitor() {
>> visitcomponent(component c) {
>> if (c instanceof idirtystateaware) {
>> if (((idirtystateaware)c).isDirty()) {
>> target.addcomponent(c);
>> }
>> return CONTINUE_BUT_DONOT_GO_DEEPER;
>> }
>> return CONTINUE;
>> }
>> }
>> }
>>
>> -igor
>>
>>
>>
>> 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]
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> 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#a12308607
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
