We can do that because all our components implement specific interfaces
which changes
the state of the component. For example
interface ILabelMethods
{
setBackground(Color color)
setForeground(Color color)
// and so on
}
and all those implementations do record the change
johan
On 8/24/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>
>
> 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]
>
>
