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