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]
