You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Makundi <ma...@koodaripalvelut.com> on 2008/06/15 20:38:26 UTC
Chaining components
Hi!
When I chain components, comboboxes and tables etc., I find myself
repeatedly solving the same problem:
* the parent component causes a data reload
* the parent component causes an ajax refresh
Has someone found a generic eventlistener-like solution to this?
My current inline implementations have become quite messy to follow
and I must make some major refactoring soon, as I am beginning to
understand how the Wicket framework operates - and it would not hurt
to plug in some neat ready solution you have come up with that keeps
the code clean and structured. I am thinking something along the lines
of a hashmap, I would just push the reloaders and refreshers there out
of sight ...
**
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Matthijs Wensveen <m....@func.nl>.
That's what I said ;)
Johan Compagner wrote:
> i think they are pointing to this one:
>
> https://issues.apache.org/jira/browse/WICKET-1312
>
> On Mon, Jun 16, 2008 at 9:21 AM, Jonathan Locke <jo...@gmail.com>
> wrote:
>
>
>> what bug # is that one?
>>
>>
>> igor.vaynberg wrote:
>>
>>> On Sun, Jun 15, 2008 at 11:38 AM, Martin Makundi
>>> <ma...@koodaripalvelut.com> wrote:
>>>
>>>> Hi!
>>>>
>>>> When I chain components, comboboxes and tables etc., I find myself
>>>> repeatedly solving the same problem:
>>>> * the parent component causes a data reload
>>>>
>>> if you chain your models properly (make child's model depend on
>>> parent's model) this should work transparently.
>>>
>>>
>>>> * the parent component causes an ajax refresh
>>>>
>>> if the parent component repaints itself then all child components are
>>> repainted as well...
>>>
>>>
>>>> Has someone found a generic eventlistener-like solution to this?
>>>>
>>> there is a patch in jira for a generic event/listener mechanism, but
>>> it wont happen until 1.5 because it requires api breaks.
>>>
>>> -igor
>>>
>>>
>>>> My current inline implementations have become quite messy to follow
>>>> and I must make some major refactoring soon, as I am beginning to
>>>> understand how the Wicket framework operates - and it would not hurt
>>>> to plug in some neat ready solution you have come up with that keeps
>>>> the code clean and structured. I am thinking something along the lines
>>>> of a hashmap, I would just push the reloaders and refreshers there out
>>>> of sight ...
>>>>
>>>> **
>>>> Martin
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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/Chaining-components-tp17853298p17859174.html
>> 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
>>
>>
>>
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Johan Compagner <jc...@gmail.com>.
i think they are pointing to this one:
https://issues.apache.org/jira/browse/WICKET-1312
On Mon, Jun 16, 2008 at 9:21 AM, Jonathan Locke <jo...@gmail.com>
wrote:
>
>
> what bug # is that one?
>
>
> igor.vaynberg wrote:
> >
> > On Sun, Jun 15, 2008 at 11:38 AM, Martin Makundi
> > <ma...@koodaripalvelut.com> wrote:
> >> Hi!
> >>
> >> When I chain components, comboboxes and tables etc., I find myself
> >> repeatedly solving the same problem:
> >> * the parent component causes a data reload
> >
> > if you chain your models properly (make child's model depend on
> > parent's model) this should work transparently.
> >
> >> * the parent component causes an ajax refresh
> >
> > if the parent component repaints itself then all child components are
> > repainted as well...
> >
> >> Has someone found a generic eventlistener-like solution to this?
> >
> > there is a patch in jira for a generic event/listener mechanism, but
> > it wont happen until 1.5 because it requires api breaks.
> >
> > -igor
> >
> >>
> >> My current inline implementations have become quite messy to follow
> >> and I must make some major refactoring soon, as I am beginning to
> >> understand how the Wicket framework operates - and it would not hurt
> >> to plug in some neat ready solution you have come up with that keeps
> >> the code clean and structured. I am thinking something along the lines
> >> of a hashmap, I would just push the reloaders and refreshers there out
> >> of sight ...
> >>
> >> **
> >> Martin
> >>
> >> ---------------------------------------------------------------------
> >> 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/Chaining-components-tp17853298p17859174.html
> 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: Chaining components
Posted by Jonathan Locke <jo...@gmail.com>.
what bug # is that one?
igor.vaynberg wrote:
>
> On Sun, Jun 15, 2008 at 11:38 AM, Martin Makundi
> <ma...@koodaripalvelut.com> wrote:
>> Hi!
>>
>> When I chain components, comboboxes and tables etc., I find myself
>> repeatedly solving the same problem:
>> * the parent component causes a data reload
>
> if you chain your models properly (make child's model depend on
> parent's model) this should work transparently.
>
>> * the parent component causes an ajax refresh
>
> if the parent component repaints itself then all child components are
> repainted as well...
>
>> Has someone found a generic eventlistener-like solution to this?
>
> there is a patch in jira for a generic event/listener mechanism, but
> it wont happen until 1.5 because it requires api breaks.
>
> -igor
>
>>
>> My current inline implementations have become quite messy to follow
>> and I must make some major refactoring soon, as I am beginning to
>> understand how the Wicket framework operates - and it would not hurt
>> to plug in some neat ready solution you have come up with that keeps
>> the code clean and structured. I am thinking something along the lines
>> of a hashmap, I would just push the reloaders and refreshers there out
>> of sight ...
>>
>> **
>> Martin
>>
>> ---------------------------------------------------------------------
>> 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/Chaining-components-tp17853298p17859174.html
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: Chaining components
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
> If you just need a reference to the AjaxRequestTarget then you can do
> RequestCycle.get().getRequestTarget() and do an instanceof with
> AjaxRequestTarget.
Well, I need the ajax event too so I suppose I can equally well pick
up the target from there. I will post my brain later if I am
succesful.
**
Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>
> ---------------------------------------------------------------------
> 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: Chaining components
Posted by Matthijs Wensveen <m....@func.nl>.
Martin Makundi wrote:
>> I've been thinking about writing aspects that fire Component.onModelChanged
>> even when the model's object changed (possibly deep within an object
>> hierarchy).
>>
>
> Do you have a demo about this?
>
Unfortunately no, I didn't have the time to convert my brain contents to
java code...
> I am about to write a HierarchicalAjaxRefreshTargetPropagator soon
> just to get a feeling if it is a bad idea... I will let subscribers
> know.
>
If you just need a reference to the AjaxRequestTarget then you can do
RequestCycle.get().getRequestTarget() and do an instanceof with
AjaxRequestTarget.
Matthijs
> **
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
> I've been thinking about writing aspects that fire Component.onModelChanged
> even when the model's object changed (possibly deep within an object
> hierarchy).
Do you have a demo about this?
I am about to write a HierarchicalAjaxRefreshTargetPropagator soon
just to get a feeling if it is a bad idea... I will let subscribers
know.
**
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Mon, 16 Jun 2008, Matthijs Wensveen wrote:
> I've been thinking about writing aspects that fire
> Component.onModelChanged even when the model's object changed (possibly
> deep within an object hierarchy). Another option would be to use
> PropertyChangeSupport. Either way, you'd never require listeners or
> other complex notification structures. This would be especially useful
> with AJAX, because then all components that get onModelChanged can add
> themselves to the AjaxRequestTarget.
That's a really interesting idea! I'm afraid that any working
solution might require too much black magic to be viable, but
please keep us posted.
> By the way, the jira patch Igor mentioned:
> https://issues.apache.org/jira/browse/WICKET-1312. I really like it.
Thanks :)
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Matthijs Wensveen <m....@func.nl>.
Martin Makundi wrote:
>>> Now if I change the country, I must change the list of allowed values
>>> for cityCombo.
>>>
>>>
>> http://wicketstuff.org/wicket13/ajax/choice
>>
>
> Thanks, I remember seeing that but already forgot about the idea that
> a dropdown choice can be a model, and a smart model too.
>
>
>> interface statechangedlistener { protected void onstatechanged(ajaxrequesttarget t); }
>> city.onupdate() { getpage().visitchildren(statechangedlistener.class) {...}}
>> there is your basic listener support.
>>
>
> Ok. Something like this. I do not know if I want to bind it directly
> to the page hierarcy though, it might be some other construct just for
> that purpose. And I do not know if I want a listener interface if I
> can make the models reload themselves -> in that case the construct
> should maybe automatically attach onchangelisteners? Maybe, e.g.,
> mutable/immutable treenodes...
>
I've been thinking about writing aspects that fire
Component.onModelChanged even when the model's object changed (possibly
deep within an object hierarchy). Another option would be to use
PropertyChangeSupport. Either way, you'd never require listeners or
other complex notification structures. This would be especially useful
with AJAX, because then all components that get onModelChanged can add
themselves to the AjaxRequestTarget.
By the way, the jira patch Igor mentioned:
https://issues.apache.org/jira/browse/WICKET-1312. I really like it.
Matthijs.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
>> Now if I change the country, I must change the list of allowed values
>> for cityCombo.
>>
> http://wicketstuff.org/wicket13/ajax/choice
Thanks, I remember seeing that but already forgot about the idea that
a dropdown choice can be a model, and a smart model too.
> interface statechangedlistener { protected void onstatechanged(ajaxrequesttarget t); }
> city.onupdate() { getpage().visitchildren(statechangedlistener.class) {...}}
> there is your basic listener support.
Ok. Something like this. I do not know if I want to bind it directly
to the page hierarcy though, it might be some other construct just for
that purpose. And I do not know if I want a listener interface if I
can make the models reload themselves -> in that case the construct
should maybe automatically attach onchangelisteners? Maybe, e.g.,
mutable/immutable treenodes...
**
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Igor Vaynberg <ig...@gmail.com>.
AbstractReadOnlyModel<List<? extends S>> { should work iirc
-igor
On Mon, Jun 16, 2008 at 7:08 AM, Martin Makundi
<ma...@koodaripalvelut.com> wrote:
>>> What is your idea of nice chaining?
>>
>> http://wicketstuff.org/wicket13/ajax/choice
>
> I am using 1.4-m1 and I tried to make
>
> public abstract class AbstractListChoiceModel<S> extends
> AbstractReadOnlyModel<List<S>> {
> @Override
> public final List<S> getObject() {
> return getChoices();
> }
>
> protected abstract List<S> getChoices();
> }
>
> The compiler complains AbstractListChoiceModel<CustomElement> is not
> compatible with IModel<List<? extends CustomElement>>
>
> Does this make sense?
>
> AbstractListChoiceModel<CustomElement> availableCustomElementsModel
> = new AbstractListChoiceModel<CustomElement>() {
> ...
> };
>
> final DropDownChoice<CustomElement> selection = new
> DropDownChoice<CustomElement>(SELECTION,
> new PropertyModel<CustomElement>(dto, CustomElement.SELECTION)),
> availableCustomElementsModel, new IChoiceRenderer<CustomElement>() {
> ...
>
> **
> Martin
>
> ---------------------------------------------------------------------
> 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: Chaining components
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
>> What is your idea of nice chaining?
>
> http://wicketstuff.org/wicket13/ajax/choice
I am using 1.4-m1 and I tried to make
public abstract class AbstractListChoiceModel<S> extends
AbstractReadOnlyModel<List<S>> {
@Override
public final List<S> getObject() {
return getChoices();
}
protected abstract List<S> getChoices();
}
The compiler complains AbstractListChoiceModel<CustomElement> is not
compatible with IModel<List<? extends CustomElement>>
Does this make sense?
AbstractListChoiceModel<CustomElement> availableCustomElementsModel
= new AbstractListChoiceModel<CustomElement>() {
...
};
final DropDownChoice<CustomElement> selection = new
DropDownChoice<CustomElement>(SELECTION,
new PropertyModel<CustomElement>(dto, CustomElement.SELECTION)),
availableCustomElementsModel, new IChoiceRenderer<CustomElement>() {
...
**
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Igor Vaynberg <ig...@gmail.com>.
On Sun, Jun 15, 2008 at 1:57 PM, Martin Makundi
<ma...@koodaripalvelut.com> wrote:
>> if you chain your models properly (make child's model depend on
>> parent's model) this should work transparently.
>
> Say I have a Person with properties Person.country and Person.city.
> Then I have a countryCombo = dropDown... and a cityCombo =
> dropDown()..
>
> Now if I change the country, I must change the list of allowed values
> for cityCombo.
>
> What is your idea of nice chaining?
http://wicketstuff.org/wicket13/ajax/choice
>
>> if the parent component repaints itself then all child components are
>> repainted as well...
>
> They are not hierarchical in the DOM sense. I have:
> countryCombo.add(onChangeAjaxBehavior() {
> // ....
> reloadCityCombo();
> ajaxRefreshCityCombo();
> }
>
> All this is manual repeating work... I would rather just have
> hierarchicalUpdate.attachChangeListener(CITY);
> hierarchicalUpdate.reload(CITY);
> hierarchicalUpdate.ajaxRefresh(CITY, target);
>
> .. or something. Haven't quite wrapped up my idea yet, but I see a lot
> of reload-refresh pattern happening which would suggest some
> centralized functionality. My greatest oncern is when I have more than
> two chained components, I sometimes get confused with the
> chain-of-command and sometimes some elements forget to refresh. If I
> had a hierarchicalUpdateManager or something, all I would need to do
> is just to attach the child component into the proper node ("on a
> global scale" instead of finding the proper line-of-code).
interface statechangedlistener { protected void
onstatechanged(ajaxrequesttarget t); }
city.onupdate() { getpage().visitchildren(statechangedlistener.class) {...}}
there is your basic listener support. then you just let your city
dropdown implement statechangedlistener and do the right thing in
onstatechanged()
-igor
>
> **
> Martin
>
>>> Has someone found a generic eventlistener-like solution to this?
>>
>> there is a patch in jira for a generic event/listener mechanism, but
>> it wont happen until 1.5 because it requires api breaks.
>>
>> -igor
>>
>
> ---------------------------------------------------------------------
> 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: Chaining components
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
> if you chain your models properly (make child's model depend on
> parent's model) this should work transparently.
Say I have a Person with properties Person.country and Person.city.
Then I have a countryCombo = dropDown... and a cityCombo =
dropDown()..
Now if I change the country, I must change the list of allowed values
for cityCombo.
What is your idea of nice chaining?
> if the parent component repaints itself then all child components are
> repainted as well...
They are not hierarchical in the DOM sense. I have:
countryCombo.add(onChangeAjaxBehavior() {
// ....
reloadCityCombo();
ajaxRefreshCityCombo();
}
All this is manual repeating work... I would rather just have
hierarchicalUpdate.attachChangeListener(CITY);
hierarchicalUpdate.reload(CITY);
hierarchicalUpdate.ajaxRefresh(CITY, target);
.. or something. Haven't quite wrapped up my idea yet, but I see a lot
of reload-refresh pattern happening which would suggest some
centralized functionality. My greatest oncern is when I have more than
two chained components, I sometimes get confused with the
chain-of-command and sometimes some elements forget to refresh. If I
had a hierarchicalUpdateManager or something, all I would need to do
is just to attach the child component into the proper node ("on a
global scale" instead of finding the proper line-of-code).
**
Martin
>> Has someone found a generic eventlistener-like solution to this?
>
> there is a patch in jira for a generic event/listener mechanism, but
> it wont happen until 1.5 because it requires api breaks.
>
> -igor
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Chaining components
Posted by Igor Vaynberg <ig...@gmail.com>.
On Sun, Jun 15, 2008 at 11:38 AM, Martin Makundi
<ma...@koodaripalvelut.com> wrote:
> Hi!
>
> When I chain components, comboboxes and tables etc., I find myself
> repeatedly solving the same problem:
> * the parent component causes a data reload
if you chain your models properly (make child's model depend on
parent's model) this should work transparently.
> * the parent component causes an ajax refresh
if the parent component repaints itself then all child components are
repainted as well...
> Has someone found a generic eventlistener-like solution to this?
there is a patch in jira for a generic event/listener mechanism, but
it wont happen until 1.5 because it requires api breaks.
-igor
>
> My current inline implementations have become quite messy to follow
> and I must make some major refactoring soon, as I am beginning to
> understand how the Wicket framework operates - and it would not hurt
> to plug in some neat ready solution you have come up with that keeps
> the code clean and structured. I am thinking something along the lines
> of a hashmap, I would just push the reloaders and refreshers there out
> of sight ...
>
> **
> Martin
>
> ---------------------------------------------------------------------
> 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