You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sam Hough <sa...@redspr.com> on 2007/08/22 13:30:20 UTC
Component Factory and code against interface
Would it make sense in Wicket to have a factory, for at least common
components like Button etc, that use interfaces rather than concrete classes
in their signature?
We have a requirement to have two target browsers. Full bells and whistles
Ajax version and some JavaScript (IE5 and IE5.5) so I thought the factory
pattern might allow me to return different components based on the client
browser.
Also, my tech lead can control what parts of a component a developer should
play with.
Maybe it is just coming from GWT or that pattern text books use Widgets as
their example for Factory pattern but it seems like a reasonable thing to
do? Anbody else tried this? Worked out well? Top tips?
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12272781
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Eelco Hillenius <ee...@gmail.com>.
On 8/24/07, Johan Compagner <jc...@gmail.com> wrote:
> 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
On top of that, it might help to override the updateModel
implementations of form components to determine whether you have
changes?
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Johan Compagner <jc...@gmail.com>.
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 <sa...@redspr.com> 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 <ig...@gmail.com> wrote:
> >> On 8/23/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> > >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> > >> >>
> >> > >> >>
> >> > >> >
> >> > >> >
> >> > >>
> >> > >> --
> >> > >> 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: users-unsubscribe@wicket.apache.org
> >> > >> For additional commands, e-mail: users-help@wicket.apache.org
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> >
> >> > --
> >> > 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: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
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 <ig...@gmail.com> wrote:
>> On 8/23/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> > >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >>
>> > >> >>
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> 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: users-unsubscribe@wicket.apache.org
>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >>
>> > >>
>> > >
>> > >
>> >
>> > --
>> > 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: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> wrote:
> On 8/23/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> > >> >> For additional commands, e-mail: users-help@wicket.apache.org
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >> --
> > >> 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: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >
> > >
> >
> > --
> > 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
So I can try and cling on to some credibility at work wasn't
ajaxfallbackbutton only added in 1.3-beta3? I think we started working with
1.3-beta2. We only switched because my Swing/AWT version needed a method not
to be final which changed in beta3...
Even worse is that my tech lead/client/boss sent me an email about
AjaxFallback??? need to check work email that it was Link not Button else I
will feel even more stupid.
I've got over my worry about non-Ajax clients getting a bigger HTML page
than they need. Seemed to add insult to injury that the users that get all
the html for every server interaction also get lots of stuff they don't
need. However it is a minority of our users and they should get a better
browser. I don't think MS supports IE5.5 anymore...
So I've stopped worrying about that and I take your reassurance about
detecting what a browser is capable of. Think I'll still try and keep the
auto dirty component tracking. Might be slightly less clean as I can't
intercept all calls to Wicket methods as some of them may be final etc...
but I don't have an excuse for such a complicated solution anymore.
Hope you don't think having OurButton etc that directly extends
AjaxFallBackButton etc is too evil!? I can hide the auto dirty component
stuff etc there... setOutputMarkupId(true) etc...
Anyway, many thanks Igor. Think you have saved me and my client from overly
complicated code.
igor.vaynberg wrote:
>
> On 9/1/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Doh, hadn't seen the AjaxFallbackButton... That definitely puts a dent in
>> my
>> current plan.
>
>
> read my second post in this long thread, i explicitly told you about this
> stuff as i thought it would fit your usecase well :)
>
> * Sending extra HTML to clients that didn't need it (we are based in the
> UK
>> and have lots of cutomers in Oz, Africa, Japan...). So the clients that
>> needed full browser refresh would get even more HTML...
>
>
> huh? if they need a full page refresh they would get more html? what do
> you
> mean?
>
> * What happens in browsers that half work? e.g. IE5.0 that has JavaScript
>> enabled but can't do Ajax properly.
>
>
> if js is on we check if it supports ajax. if it doesnt the fallback
> behavior
> executes.
>
> -igor
>
>
> Guess I can still hide the AjaxTarget stuff via OurButton etc that extends
>> AjaxFallbackButton, setOutputMarkupId(true) etc..., unify the event
>> handlers...
>>
>> Guess you were right. No fun writing code the same way as everybody else
>> even if it is simpler, quicker and less buggy ;)
>>
>>
>> igor.vaynberg wrote:
>> >
>> > yeah, im def not saying that _everything_ will work like that, but it
>> is
>> > _possible_ to do it. what we did is already cover the most common
>> things
>> > like links and form submit buttons.
>> >
>> > so try to get that case working first
>> >
>> > instead of switching between button and ajaxbutton use
>> ajaxfallbackbutton.
>> > what will happen is that your app will work with ajax in a browser, but
>> as
>> > soon as you turn javascript off it will work with regular requests. all
>> > pretty much transparent.
>> >
>> > when you get that working the next step will be to crate a
>> > ajaxfallbackdropdown that will do ajax onchange notifications where
>> > possible, and fallback on regular when not. you can build a layer of
>> these
>> > ajaxfallback components for your app. that is probably the way to go.
>> it
>> > isnt 100% flexible, but you can work on that later. one step at a time.
>> >
>> > -igor
>> >
>> >
>> > On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>> >>
>> >>
>> >> Igor,
>> >>
>> >> Thanks. I did have a look at that early on (so maybe I wasn't thinking
>> >> Wicket enough to get it). It seemed to me that that didn't really help
>> >> for
>> >> things like forms etc that we want to work in Ajax style (partial
>> update
>> >> etc) and with full page refresh (only JavaScript being onchange for
>> >> select
>> >> element).
>> >>
>> >> Our test example for our prototype is a query builder where you can
>> >> add/remove conditions and part of the form changes if you change what
>> >> field
>> >> you are searching. I can't see how to do this without switching
>> between
>> >> AjaxButton and Button depending on type of browser... Also changing if
>> >> ListChoice uses the AjaxFormComponentUpdatingBehavior or
>> >> onSelectionChanged...
>> >>
>> >> Wicket seems setup to allow power users to build very intricate Ajax
>> app
>> >> _OR_ plain HTML not really both at the same time.
>> >>
>> >> Sorry if I'm being thick. Think I'm bright enough for your original
>> >> comment
>> >> to worry me. Trying to grow out of the sort of geek who always has to
>> >> rewrite everything ;)
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > we already have support for "unobtrusive" ajax via AjaxFallbackLink
>> and
>> >> > AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think
>> it
>> >> will
>> >> > be just what you are looking for.
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >> > On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>> >> >>
>> >> >>
>> >> >> igor,
>> >> >>
>> >> >> I've not been able to get rid of the requirement I've been given to
>> >> >> support
>> >> >> an Ajax capable client and old browser with tiny bit of JavaScript.
>> >> Your
>> >> >> words seem more true than ever but I can't think of a better way of
>> >> doing
>> >> >> it
>> >> >> than the Swing/AWT style with our own simple objects being proxies
>> to
>> >> >> different Wicket components. e.g. AjaxButton or Button... What
>> would
>> >> you
>> >> >> do
>> >> >> if you were me? Before I try and make our prototype ship shape ;)
>> >> >>
>> >> >> Today your words seemed even more true as I'm tempted to digress
>> from
>> >> the
>> >> >> Wicket style and use event handler style: someButton.add(new
>> >> >> EventHandler...
>> >> >> So as you say writing our own framework.
>> >> >>
>> >> >>
>> >> >> igor.vaynberg wrote:
>> >> >> >
>> >> >> > the ui layer is generally not portable. if you start building
>> your
>> >> own
>> >> >> > abstraction to make it portable you will end up with a pretty big
>> >> mess
>> >> >> > because you will be working against whatever framework you are
>> using
>> >> >> and
>> >> >> > eventually that abstraction will turn into a framework itself.
>> >> >> >
>> >> >> > -igor
>> >> >> >
>> >> >> >
>> >> >> > On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> Many thanks Igor, that sounds like a very pragmatic approach. I
>> was
>> >> >> >> thinking
>> >> >> >> about all sorts of horrible kludges like re-rendering the whole
>> >> page
>> >> >> and
>> >> >> >> seeing how elements changed or hooking into the serialisation.
>> >> >> >>
>> >> >> >> Taken away another reason to do my over complicated solution ;)
>> Am
>> >> I
>> >> >> >> worrying over nothing that developers might get carried away
>> using
>> >> >> vast
>> >> >> >> number of components and fiddling with attributes that will make
>> >> the
>> >> >> >> application difficult to test and maybe one day port?
>> Restricting
>> >> the
>> >> >> set
>> >> >> >> of
>> >> >> >> components can presumably end up with a more consistent UI...
>> >> >> >>
>> >> >> >> Anyway, thanks for all your time and sage advice.
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12441886
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12446696
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
On 9/1/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Doh, hadn't seen the AjaxFallbackButton... That definitely puts a dent in
> my
> current plan.
read my second post in this long thread, i explicitly told you about this
stuff as i thought it would fit your usecase well :)
* Sending extra HTML to clients that didn't need it (we are based in the UK
> and have lots of cutomers in Oz, Africa, Japan...). So the clients that
> needed full browser refresh would get even more HTML...
huh? if they need a full page refresh they would get more html? what do you
mean?
* What happens in browsers that half work? e.g. IE5.0 that has JavaScript
> enabled but can't do Ajax properly.
if js is on we check if it supports ajax. if it doesnt the fallback behavior
executes.
-igor
Guess I can still hide the AjaxTarget stuff via OurButton etc that extends
> AjaxFallbackButton, setOutputMarkupId(true) etc..., unify the event
> handlers...
>
> Guess you were right. No fun writing code the same way as everybody else
> even if it is simpler, quicker and less buggy ;)
>
>
> igor.vaynberg wrote:
> >
> > yeah, im def not saying that _everything_ will work like that, but it is
> > _possible_ to do it. what we did is already cover the most common things
> > like links and form submit buttons.
> >
> > so try to get that case working first
> >
> > instead of switching between button and ajaxbutton use
> ajaxfallbackbutton.
> > what will happen is that your app will work with ajax in a browser, but
> as
> > soon as you turn javascript off it will work with regular requests. all
> > pretty much transparent.
> >
> > when you get that working the next step will be to crate a
> > ajaxfallbackdropdown that will do ajax onchange notifications where
> > possible, and fallback on regular when not. you can build a layer of
> these
> > ajaxfallback components for your app. that is probably the way to go. it
> > isnt 100% flexible, but you can work on that later. one step at a time.
> >
> > -igor
> >
> >
> > On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
> >>
> >>
> >> Igor,
> >>
> >> Thanks. I did have a look at that early on (so maybe I wasn't thinking
> >> Wicket enough to get it). It seemed to me that that didn't really help
> >> for
> >> things like forms etc that we want to work in Ajax style (partial
> update
> >> etc) and with full page refresh (only JavaScript being onchange for
> >> select
> >> element).
> >>
> >> Our test example for our prototype is a query builder where you can
> >> add/remove conditions and part of the form changes if you change what
> >> field
> >> you are searching. I can't see how to do this without switching between
> >> AjaxButton and Button depending on type of browser... Also changing if
> >> ListChoice uses the AjaxFormComponentUpdatingBehavior or
> >> onSelectionChanged...
> >>
> >> Wicket seems setup to allow power users to build very intricate Ajax
> app
> >> _OR_ plain HTML not really both at the same time.
> >>
> >> Sorry if I'm being thick. Think I'm bright enough for your original
> >> comment
> >> to worry me. Trying to grow out of the sort of geek who always has to
> >> rewrite everything ;)
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > we already have support for "unobtrusive" ajax via AjaxFallbackLink
> and
> >> > AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it
> >> will
> >> > be just what you are looking for.
> >> >
> >> > -igor
> >> >
> >> >
> >> > On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
> >> >>
> >> >>
> >> >> igor,
> >> >>
> >> >> I've not been able to get rid of the requirement I've been given to
> >> >> support
> >> >> an Ajax capable client and old browser with tiny bit of JavaScript.
> >> Your
> >> >> words seem more true than ever but I can't think of a better way of
> >> doing
> >> >> it
> >> >> than the Swing/AWT style with our own simple objects being proxies
> to
> >> >> different Wicket components. e.g. AjaxButton or Button... What would
> >> you
> >> >> do
> >> >> if you were me? Before I try and make our prototype ship shape ;)
> >> >>
> >> >> Today your words seemed even more true as I'm tempted to digress
> from
> >> the
> >> >> Wicket style and use event handler style: someButton.add(new
> >> >> EventHandler...
> >> >> So as you say writing our own framework.
> >> >>
> >> >>
> >> >> igor.vaynberg wrote:
> >> >> >
> >> >> > the ui layer is generally not portable. if you start building your
> >> own
> >> >> > abstraction to make it portable you will end up with a pretty big
> >> mess
> >> >> > because you will be working against whatever framework you are
> using
> >> >> and
> >> >> > eventually that abstraction will turn into a framework itself.
> >> >> >
> >> >> > -igor
> >> >> >
> >> >> >
> >> >> > On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >> Many thanks Igor, that sounds like a very pragmatic approach. I
> was
> >> >> >> thinking
> >> >> >> about all sorts of horrible kludges like re-rendering the whole
> >> page
> >> >> and
> >> >> >> seeing how elements changed or hooking into the serialisation.
> >> >> >>
> >> >> >> Taken away another reason to do my over complicated solution ;)
> Am
> >> I
> >> >> >> worrying over nothing that developers might get carried away
> using
> >> >> vast
> >> >> >> number of components and fiddling with attributes that will make
> >> the
> >> >> >> application difficult to test and maybe one day port? Restricting
> >> the
> >> >> set
> >> >> >> of
> >> >> >> components can presumably end up with a more consistent UI...
> >> >> >>
> >> >> >> Anyway, thanks for all your time and sage advice.
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12441886
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
Doh, hadn't seen the AjaxFallbackButton... That definitely puts a dent in my
current plan. I still like being able to hide/expose as much of the Wicket
API as I like and intercept methods to mark the component dirty but looks
less worth it. As I'm sure you imagined I needed to fiddle with the
resolution of SomeClass.html...
Guess I'll have to look at the AjaxFallbackXXX code properly. I think my
initial concerns were:
* Sending extra HTML to clients that didn't need it (we are based in the UK
and have lots of cutomers in Oz, Africa, Japan...). So the clients that
needed full browser refresh would get even more HTML...
* What happens in browsers that half work? e.g. IE5.0 that has JavaScript
enabled but can't do Ajax properly.
Guess I can still hide the AjaxTarget stuff via OurButton etc that extends
AjaxFallbackButton, setOutputMarkupId(true) etc..., unify the event
handlers...
Guess you were right. No fun writing code the same way as everybody else
even if it is simpler, quicker and less buggy ;)
igor.vaynberg wrote:
>
> yeah, im def not saying that _everything_ will work like that, but it is
> _possible_ to do it. what we did is already cover the most common things
> like links and form submit buttons.
>
> so try to get that case working first
>
> instead of switching between button and ajaxbutton use ajaxfallbackbutton.
> what will happen is that your app will work with ajax in a browser, but as
> soon as you turn javascript off it will work with regular requests. all
> pretty much transparent.
>
> when you get that working the next step will be to crate a
> ajaxfallbackdropdown that will do ajax onchange notifications where
> possible, and fallback on regular when not. you can build a layer of these
> ajaxfallback components for your app. that is probably the way to go. it
> isnt 100% flexible, but you can work on that later. one step at a time.
>
> -igor
>
>
> On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Igor,
>>
>> Thanks. I did have a look at that early on (so maybe I wasn't thinking
>> Wicket enough to get it). It seemed to me that that didn't really help
>> for
>> things like forms etc that we want to work in Ajax style (partial update
>> etc) and with full page refresh (only JavaScript being onchange for
>> select
>> element).
>>
>> Our test example for our prototype is a query builder where you can
>> add/remove conditions and part of the form changes if you change what
>> field
>> you are searching. I can't see how to do this without switching between
>> AjaxButton and Button depending on type of browser... Also changing if
>> ListChoice uses the AjaxFormComponentUpdatingBehavior or
>> onSelectionChanged...
>>
>> Wicket seems setup to allow power users to build very intricate Ajax app
>> _OR_ plain HTML not really both at the same time.
>>
>> Sorry if I'm being thick. Think I'm bright enough for your original
>> comment
>> to worry me. Trying to grow out of the sort of geek who always has to
>> rewrite everything ;)
>>
>>
>> igor.vaynberg wrote:
>> >
>> > we already have support for "unobtrusive" ajax via AjaxFallbackLink and
>> > AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it
>> will
>> > be just what you are looking for.
>> >
>> > -igor
>> >
>> >
>> > On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>> >>
>> >>
>> >> igor,
>> >>
>> >> I've not been able to get rid of the requirement I've been given to
>> >> support
>> >> an Ajax capable client and old browser with tiny bit of JavaScript.
>> Your
>> >> words seem more true than ever but I can't think of a better way of
>> doing
>> >> it
>> >> than the Swing/AWT style with our own simple objects being proxies to
>> >> different Wicket components. e.g. AjaxButton or Button... What would
>> you
>> >> do
>> >> if you were me? Before I try and make our prototype ship shape ;)
>> >>
>> >> Today your words seemed even more true as I'm tempted to digress from
>> the
>> >> Wicket style and use event handler style: someButton.add(new
>> >> EventHandler...
>> >> So as you say writing our own framework.
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > the ui layer is generally not portable. if you start building your
>> own
>> >> > abstraction to make it portable you will end up with a pretty big
>> mess
>> >> > because you will be working against whatever framework you are using
>> >> and
>> >> > eventually that abstraction will turn into a framework itself.
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >> > On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
>> >> >>
>> >> >>
>> >> >> Many thanks Igor, that sounds like a very pragmatic approach. I was
>> >> >> thinking
>> >> >> about all sorts of horrible kludges like re-rendering the whole
>> page
>> >> and
>> >> >> seeing how elements changed or hooking into the serialisation.
>> >> >>
>> >> >> Taken away another reason to do my over complicated solution ;) Am
>> I
>> >> >> worrying over nothing that developers might get carried away using
>> >> vast
>> >> >> number of components and fiddling with attributes that will make
>> the
>> >> >> application difficult to test and maybe one day port? Restricting
>> the
>> >> set
>> >> >> of
>> >> >> components can presumably end up with a more consistent UI...
>> >> >>
>> >> >> Anyway, thanks for all your time and sage advice.
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12441886
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
yeah, im def not saying that _everything_ will work like that, but it is
_possible_ to do it. what we did is already cover the most common things
like links and form submit buttons.
so try to get that case working first
instead of switching between button and ajaxbutton use ajaxfallbackbutton.
what will happen is that your app will work with ajax in a browser, but as
soon as you turn javascript off it will work with regular requests. all
pretty much transparent.
when you get that working the next step will be to crate a
ajaxfallbackdropdown that will do ajax onchange notifications where
possible, and fallback on regular when not. you can build a layer of these
ajaxfallback components for your app. that is probably the way to go. it
isnt 100% flexible, but you can work on that later. one step at a time.
-igor
On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Igor,
>
> Thanks. I did have a look at that early on (so maybe I wasn't thinking
> Wicket enough to get it). It seemed to me that that didn't really help for
> things like forms etc that we want to work in Ajax style (partial update
> etc) and with full page refresh (only JavaScript being onchange for select
> element).
>
> Our test example for our prototype is a query builder where you can
> add/remove conditions and part of the form changes if you change what
> field
> you are searching. I can't see how to do this without switching between
> AjaxButton and Button depending on type of browser... Also changing if
> ListChoice uses the AjaxFormComponentUpdatingBehavior or
> onSelectionChanged...
>
> Wicket seems setup to allow power users to build very intricate Ajax app
> _OR_ plain HTML not really both at the same time.
>
> Sorry if I'm being thick. Think I'm bright enough for your original
> comment
> to worry me. Trying to grow out of the sort of geek who always has to
> rewrite everything ;)
>
>
> igor.vaynberg wrote:
> >
> > we already have support for "unobtrusive" ajax via AjaxFallbackLink and
> > AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it
> will
> > be just what you are looking for.
> >
> > -igor
> >
> >
> > On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
> >>
> >>
> >> igor,
> >>
> >> I've not been able to get rid of the requirement I've been given to
> >> support
> >> an Ajax capable client and old browser with tiny bit of JavaScript.
> Your
> >> words seem more true than ever but I can't think of a better way of
> doing
> >> it
> >> than the Swing/AWT style with our own simple objects being proxies to
> >> different Wicket components. e.g. AjaxButton or Button... What would
> you
> >> do
> >> if you were me? Before I try and make our prototype ship shape ;)
> >>
> >> Today your words seemed even more true as I'm tempted to digress from
> the
> >> Wicket style and use event handler style: someButton.add(new
> >> EventHandler...
> >> So as you say writing our own framework.
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > the ui layer is generally not portable. if you start building your
> own
> >> > abstraction to make it portable you will end up with a pretty big
> mess
> >> > because you will be working against whatever framework you are using
> >> and
> >> > eventually that abstraction will turn into a framework itself.
> >> >
> >> > -igor
> >> >
> >> >
> >> > On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
> >> >>
> >> >>
> >> >> Many thanks Igor, that sounds like a very pragmatic approach. I was
> >> >> thinking
> >> >> about all sorts of horrible kludges like re-rendering the whole page
> >> and
> >> >> seeing how elements changed or hooking into the serialisation.
> >> >>
> >> >> Taken away another reason to do my over complicated solution ;) Am I
> >> >> worrying over nothing that developers might get carried away using
> >> vast
> >> >> number of components and fiddling with attributes that will make the
> >> >> application difficult to test and maybe one day port? Restricting
> the
> >> set
> >> >> of
> >> >> components can presumably end up with a more consistent UI...
> >> >>
> >> >> Anyway, thanks for all your time and sage advice.
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
Igor,
Thanks. I did have a look at that early on (so maybe I wasn't thinking
Wicket enough to get it). It seemed to me that that didn't really help for
things like forms etc that we want to work in Ajax style (partial update
etc) and with full page refresh (only JavaScript being onchange for select
element).
Our test example for our prototype is a query builder where you can
add/remove conditions and part of the form changes if you change what field
you are searching. I can't see how to do this without switching between
AjaxButton and Button depending on type of browser... Also changing if
ListChoice uses the AjaxFormComponentUpdatingBehavior or
onSelectionChanged...
Wicket seems setup to allow power users to build very intricate Ajax app
_OR_ plain HTML not really both at the same time.
Sorry if I'm being thick. Think I'm bright enough for your original comment
to worry me. Trying to grow out of the sort of geek who always has to
rewrite everything ;)
igor.vaynberg wrote:
>
> we already have support for "unobtrusive" ajax via AjaxFallbackLink and
> AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it will
> be just what you are looking for.
>
> -igor
>
>
> On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> igor,
>>
>> I've not been able to get rid of the requirement I've been given to
>> support
>> an Ajax capable client and old browser with tiny bit of JavaScript. Your
>> words seem more true than ever but I can't think of a better way of doing
>> it
>> than the Swing/AWT style with our own simple objects being proxies to
>> different Wicket components. e.g. AjaxButton or Button... What would you
>> do
>> if you were me? Before I try and make our prototype ship shape ;)
>>
>> Today your words seemed even more true as I'm tempted to digress from the
>> Wicket style and use event handler style: someButton.add(new
>> EventHandler...
>> So as you say writing our own framework.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > the ui layer is generally not portable. if you start building your own
>> > abstraction to make it portable you will end up with a pretty big mess
>> > because you will be working against whatever framework you are using
>> and
>> > eventually that abstraction will turn into a framework itself.
>> >
>> > -igor
>> >
>> >
>> > On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
>> >>
>> >>
>> >> Many thanks Igor, that sounds like a very pragmatic approach. I was
>> >> thinking
>> >> about all sorts of horrible kludges like re-rendering the whole page
>> and
>> >> seeing how elements changed or hooking into the serialisation.
>> >>
>> >> Taken away another reason to do my over complicated solution ;) Am I
>> >> worrying over nothing that developers might get carried away using
>> vast
>> >> number of components and fiddling with attributes that will make the
>> >> application difficult to test and maybe one day port? Restricting the
>> set
>> >> of
>> >> components can presumably end up with a more consistent UI...
>> >>
>> >> Anyway, thanks for all your time and sage advice.
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
we already have support for "unobtrusive" ajax via AjaxFallbackLink and
AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it will
be just what you are looking for.
-igor
On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> igor,
>
> I've not been able to get rid of the requirement I've been given to
> support
> an Ajax capable client and old browser with tiny bit of JavaScript. Your
> words seem more true than ever but I can't think of a better way of doing
> it
> than the Swing/AWT style with our own simple objects being proxies to
> different Wicket components. e.g. AjaxButton or Button... What would you
> do
> if you were me? Before I try and make our prototype ship shape ;)
>
> Today your words seemed even more true as I'm tempted to digress from the
> Wicket style and use event handler style: someButton.add(new
> EventHandler...
> So as you say writing our own framework.
>
>
> igor.vaynberg wrote:
> >
> > the ui layer is generally not portable. if you start building your own
> > abstraction to make it portable you will end up with a pretty big mess
> > because you will be working against whatever framework you are using and
> > eventually that abstraction will turn into a framework itself.
> >
> > -igor
> >
> >
> > On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
> >>
> >>
> >> Many thanks Igor, that sounds like a very pragmatic approach. I was
> >> thinking
> >> about all sorts of horrible kludges like re-rendering the whole page
> and
> >> seeing how elements changed or hooking into the serialisation.
> >>
> >> Taken away another reason to do my over complicated solution ;) Am I
> >> worrying over nothing that developers might get carried away using vast
> >> number of components and fiddling with attributes that will make the
> >> application difficult to test and maybe one day port? Restricting the
> set
> >> of
> >> components can presumably end up with a more consistent UI...
> >>
> >> Anyway, thanks for all your time and sage advice.
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
igor,
I've not been able to get rid of the requirement I've been given to support
an Ajax capable client and old browser with tiny bit of JavaScript. Your
words seem more true than ever but I can't think of a better way of doing it
than the Swing/AWT style with our own simple objects being proxies to
different Wicket components. e.g. AjaxButton or Button... What would you do
if you were me? Before I try and make our prototype ship shape ;)
Today your words seemed even more true as I'm tempted to digress from the
Wicket style and use event handler style: someButton.add(new EventHandler...
So as you say writing our own framework.
igor.vaynberg wrote:
>
> the ui layer is generally not portable. if you start building your own
> abstraction to make it portable you will end up with a pretty big mess
> because you will be working against whatever framework you are using and
> eventually that abstraction will turn into a framework itself.
>
> -igor
>
>
> On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Many thanks Igor, that sounds like a very pragmatic approach. I was
>> thinking
>> about all sorts of horrible kludges like re-rendering the whole page and
>> seeing how elements changed or hooking into the serialisation.
>>
>> Taken away another reason to do my over complicated solution ;) Am I
>> worrying over nothing that developers might get carried away using vast
>> number of components and fiddling with attributes that will make the
>> application difficult to test and maybe one day port? Restricting the set
>> of
>> components can presumably end up with a more consistent UI...
>>
>> Anyway, thanks for all your time and sage advice.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
Igor,
We are not really trying to make it portable or our own abstraction. The aim
would be a subset of the non-ajax Wicket API. In my comfortable ignorance it
is a nice way to keep track of dirty components, hide details of
ajax/non-ajax and let our tech lead keep firm control over which bits of
wicket we use.
I'm totally with you that this could turn into a real pain. Container
systems like EJB2, Swing etc suggest it can go horribly wrong.
igor.vaynberg wrote:
>
> the ui layer is generally not portable. if you start building your own
> abstraction to make it portable you will end up with a pretty big mess
> because you will be working against whatever framework you are using and
> eventually that abstraction will turn into a framework itself.
>
> -igor
>
>
> On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Many thanks Igor, that sounds like a very pragmatic approach. I was
>> thinking
>> about all sorts of horrible kludges like re-rendering the whole page and
>> seeing how elements changed or hooking into the serialisation.
>>
>> Taken away another reason to do my over complicated solution ;) Am I
>> worrying over nothing that developers might get carried away using vast
>> number of components and fiddling with attributes that will make the
>> application difficult to test and maybe one day port? Restricting the set
>> of
>> components can presumably end up with a more consistent UI...
>>
>> Anyway, thanks for all your time and sage advice.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12317759
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
the ui layer is generally not portable. if you start building your own
abstraction to make it portable you will end up with a pretty big mess
because you will be working against whatever framework you are using and
eventually that abstraction will turn into a framework itself.
-igor
On 8/24/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Many thanks Igor, that sounds like a very pragmatic approach. I was
> thinking
> about all sorts of horrible kludges like re-rendering the whole page and
> seeing how elements changed or hooking into the serialisation.
>
> Taken away another reason to do my over complicated solution ;) Am I
> worrying over nothing that developers might get carried away using vast
> number of components and fiddling with attributes that will make the
> application difficult to test and maybe one day port? Restricting the set
> of
> components can presumably end up with a more consistent UI...
>
> Anyway, thanks for all your time and sage advice.
>
> --
> View this message in context:
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
Many thanks Igor, that sounds like a very pragmatic approach. I was thinking
about all sorts of horrible kludges like re-rendering the whole page and
seeing how elements changed or hooking into the serialisation.
Taken away another reason to do my over complicated solution ;) Am I
worrying over nothing that developers might get carried away using vast
number of components and fiddling with attributes that will make the
application difficult to test and maybe one day port? Restricting the set of
components can presumably end up with a more consistent UI...
Anyway, thanks for all your time and sage advice.
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
On 8/23/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Eelco Hillenius <ee...@gmail.com>.
> I have the habit of having a fixUpTheStateOfThisWidget method (real name
> changed to protect the guilty) that I'm starting to wonder if I can hook
> this into marking components as dirty. So maybe I can get away with explicit
> marking of components as dirty.
Or e.g. work with bean properties and use property change listeners.
> Perhaps coming from GWT I imagined Wicket would magically handle all the
> state changes for me. All the AjaxTarget stuff seems very low level for
> writing user interfaces.
Yeah. Thing is that everything in Wicket works automatically for
normal processing. Since GWT is Ajax only, and they 'own' everything
that happens in the browser, they can do that. The way Ajax with
Wicket currently works is very flexible etc, but agreed requires more
hand work.
It's not a static framework though. We're always on the lookout for
improving things, and this might be an area for that. You could open a
JIRA issue (feature request) for it so that we make this discussion
more persistent. And of course, please share any insights you might
develop while working on this.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
Thanks Eelco,
It is mainly navigation logic and I think its state can quite happily live
in the components...
I have the habit of having a fixUpTheStateOfThisWidget method (real name
changed to protect the guilty) that I'm starting to wonder if I can hook
this into marking components as dirty. So maybe I can get away with explicit
marking of components as dirty. So at least my application code does not see
the gory details of Ajax, code handlers only once and changes get
cascaded... Anyway, I'll see if I can manage without setEnabled, setVisible,
add, addOrReplace etc not being final...
Perhaps coming from GWT I imagined Wicket would magically handle all the
state changes for me. All the AjaxTarget stuff seems very low level for
writing user interfaces.
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12483783
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/4/07, Sam Hough <sa...@redspr.com> wrote:
>
> Thanks Johan and Eelco,
>
> I'm going to consider the model as opaque as far as change tracking is
> concerned. I just want an easy way to track dirty components so looks like
> this is the way to go unless it is going away completely. Since so many
> methods are final the only options I can think of are polling components for
> change, our own build of Wicket, explicit marking or AOP. None of which
> sound attractive.
If some finals are in the way, and you have a real good use case for
us, we can always consider removing. We've done that in the past.
As for your strategy to track dirty components... I'm really not sure
now whether using Wicket's change mechanism is the best way to go.
Like Johan said, what is done with it depends on the version manager
in use, which depends on the session store in use. We might have to
remove final from Component#addStateChange to facilitate listening to
changes without having to jump through too many loop holes.
I'm still wondering whether it is really the component changes you are
after. If you are building something completely generic, maybe yes,
and maybe this should be part of Wicket then. Otoh, I expect that
typical applications are actually interested in reflecting data
changes, which are typically not communicated through component
changes. The problem is though, that for the sake of efficiency, we
only pull data when we need it. I.e. when rendering the components.
And as with Ajax you only want to do partial renders... Though one
this.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
Thanks Johan and Eelco,
I'm going to consider the model as opaque as far as change tracking is
concerned. I just want an easy way to track dirty components so looks like
this is the way to go unless it is going away completely. Since so many
methods are final the only options I can think of are polling components for
change, our own build of Wicket, explicit marking or AOP. None of which
sound attractive.
btw Using wicket is so so nice compared to struts etc. Turns out I'm the
weakest link trying to remember how to program in OO ;) Many thanks to you
and the other developers.
Johan Compagner wrote:
>
> a bit more info: in wicket 1.3 (default with SLC) the change objects
> aren't
> really used anymore
> (they are not stored). They only cause an increment of the page version
> number..
>
> johan
>
> On 9/3/07, Eelco Hillenius <ee...@gmail.com> wrote:
>>
>> > igor.vaynberg wrote:
>> > >
>> > > On 8/23/07, Sam Hough <sa...@redspr.com> wrote:
>> > >
>> > >> heh, there is nothing that automatically marks components as dirty()
>> > >> because
>> > >> wicket doesnt know what you do inside your components. wicket is
>> > >> unmanaged.
>> > >
>> > If I do Component.setVersioned(true) and hook in my own
>> IPageVersionManager
>> > won't Wicket effectively track dirty components for me? In a lot of
>> user
>> > interactions very few components will change so presumably using Wicket
>> > component level versioning would be more effecient for us? It won't
>> track
>> > everything but since setEnabled, setVisible etc are final I've not that
>> many
>> > choices...
>>
>> Wicket's change tracking is only done for explicit changes though. For
>> instance:
>>
>> private class CurrentPageChange extends Change {
>> private final int currentPage;
>>
>> CurrentPageChange(int currentPage) {
>> this.currentPage = currentPage;
>> }
>>
>> public void undo() {
>> setCurrentPage(currentPage);
>> }
>> }
>>
>> ...
>> addStateChange(new CurrentPageChange(this.currentPage));
>>
>>
>> You can definitively use this for your own purposes. However, I would
>> think that the typical thing *you* want to react on are model changes.
>> You can use this mechanism for it as well, but it might be heavier
>> than you'd like.
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12473771
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Johan Compagner <jc...@gmail.com>.
a bit more info: in wicket 1.3 (default with SLC) the change objects aren't
really used anymore
(they are not stored). They only cause an increment of the page version
number..
johan
On 9/3/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > igor.vaynberg wrote:
> > >
> > > On 8/23/07, Sam Hough <sa...@redspr.com> wrote:
> > >
> > >> heh, there is nothing that automatically marks components as dirty()
> > >> because
> > >> wicket doesnt know what you do inside your components. wicket is
> > >> unmanaged.
> > >
> > If I do Component.setVersioned(true) and hook in my own
> IPageVersionManager
> > won't Wicket effectively track dirty components for me? In a lot of user
> > interactions very few components will change so presumably using Wicket
> > component level versioning would be more effecient for us? It won't
> track
> > everything but since setEnabled, setVisible etc are final I've not that
> many
> > choices...
>
> Wicket's change tracking is only done for explicit changes though. For
> instance:
>
> private class CurrentPageChange extends Change {
> private final int currentPage;
>
> CurrentPageChange(int currentPage) {
> this.currentPage = currentPage;
> }
>
> public void undo() {
> setCurrentPage(currentPage);
> }
> }
>
> ...
> addStateChange(new CurrentPageChange(this.currentPage));
>
>
> You can definitively use this for your own purposes. However, I would
> think that the typical thing *you* want to react on are model changes.
> You can use this mechanism for it as well, but it might be heavier
> than you'd like.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Eelco Hillenius <ee...@gmail.com>.
> igor.vaynberg wrote:
> >
> > On 8/23/07, Sam Hough <sa...@redspr.com> wrote:
> >
> >> heh, there is nothing that automatically marks components as dirty()
> >> because
> >> wicket doesnt know what you do inside your components. wicket is
> >> unmanaged.
> >
> If I do Component.setVersioned(true) and hook in my own IPageVersionManager
> won't Wicket effectively track dirty components for me? In a lot of user
> interactions very few components will change so presumably using Wicket
> component level versioning would be more effecient for us? It won't track
> everything but since setEnabled, setVisible etc are final I've not that many
> choices...
Wicket's change tracking is only done for explicit changes though. For instance:
private class CurrentPageChange extends Change {
private final int currentPage;
CurrentPageChange(int currentPage) {
this.currentPage = currentPage;
}
public void undo() {
setCurrentPage(currentPage);
}
}
...
addStateChange(new CurrentPageChange(this.currentPage));
You can definitively use this for your own purposes. However, I would
think that the typical thing *you* want to react on are model changes.
You can use this mechanism for it as well, but it might be heavier
than you'd like.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
igor.vaynberg wrote:
>
> On 8/23/07, Sam Hough <sa...@redspr.com> wrote:
>
>> heh, there is nothing that automatically marks components as dirty()
>> because
>> wicket doesnt know what you do inside your components. wicket is
>> unmanaged.
>
If I do Component.setVersioned(true) and hook in my own IPageVersionManager
won't Wicket effectively track dirty components for me? In a lot of user
interactions very few components will change so presumably using Wicket
component level versioning would be more effecient for us? It won't track
everything but since setEnabled, setVisible etc are final I've not that many
choices...
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12461509
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
On 8/23/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
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...
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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Sam Hough <sa...@redspr.com>.
I could have made it a lot clearer by saying that the factory would produce
objects inside a Wicket container. So as Swing uses AWT as a container we
would use adapted Wicket components as the containers...
Sorry, have never done any Swing so the analogy wasn't obvious. Been in
struts like world for too long.
igor.vaynberg wrote:
>
> i dont see why it wouldnt work for you. i know some people who use osgi
> with
> wicket did this a while ago and no problems.
>
> -igor
>
> On 8/22/07, Sam Hough <sa...@redspr.com> wrote:
>>
>>
>> Would it make sense in Wicket to have a factory, for at least common
>> components like Button etc, that use interfaces rather than concrete
>> classes
>> in their signature?
>>
>> We have a requirement to have two target browsers. Full bells and
>> whistles
>> Ajax version and some JavaScript (IE5 and IE5.5) so I thought the factory
>> pattern might allow me to return different components based on the client
>> browser.
>>
>> Also, my tech lead can control what parts of a component a developer
>> should
>> play with.
>>
>> Maybe it is just coming from GWT or that pattern text books use Widgets
>> as
>> their example for Factory pattern but it seems like a reasonable thing to
>> do? Anbody else tried this? Worked out well? Top tips?
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12272781
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12310411
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Component Factory and code against interface
Posted by Igor Vaynberg <ig...@gmail.com>.
i dont see why it wouldnt work for you. i know some people who use osgi with
wicket did this a while ago and no problems.
-igor
On 8/22/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Would it make sense in Wicket to have a factory, for at least common
> components like Button etc, that use interfaces rather than concrete
> classes
> in their signature?
>
> We have a requirement to have two target browsers. Full bells and whistles
> Ajax version and some JavaScript (IE5 and IE5.5) so I thought the factory
> pattern might allow me to return different components based on the client
> browser.
>
> Also, my tech lead can control what parts of a component a developer
> should
> play with.
>
> Maybe it is just coming from GWT or that pattern text books use Widgets as
> their example for Factory pattern but it seems like a reasonable thing to
> do? Anbody else tried this? Worked out well? Top tips?
>
>
> --
> View this message in context:
> http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12272781
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>