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/09/24 11:38:50 UTC
Inter component events?
Has anybody used something like javax.swing.ListModel.addListDataListener or
java.util.Observable to setup a nice way for components to respond to
changes in other components?
My use case is that I have a "basket" of items a user has selected. While
they are searching/browsing if an item already in the basket appears again I
want it to be disabled/greyed out. With hand coding that is a bit ugly and
seems like a candidate for some sort listening to changes in another
component.
--
View this message in context: http://www.nabble.com/Inter-component-events--tf4508127.html#a12856778
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: Inter component events?
Posted by ChuckDeal <cd...@csc.com>.
Here is a thread where I posted a quickstart with our solution:
http://www.nabble.com/Best-Practices-for-accessing-repainting-sibling-cousin-components--tf3841514.html#a10895313.
This is with Wicket 1.3.0
The basic idea is that a component registers itself as a listener to another
component and the list of registered lisenters is stored in the component's
metadata.
Chuck
Sam Hough wrote:
>
> Maybe something like:
> http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-subscriber.html?page=4
>
> No big extra jars...
>
> Would be nice if buttons could just subscribe to some standard set of
> messages (e.g. change of focus)
>
>
> Wouter Huijnink wrote:
>>
>>
>>> I see that it is not such an obvious win here as with fat client but how
>>> about another of my use cases:
>>> * Large page with small parts being updated by Ajax
>>> * Two components sitting long way apart in the tree (context sensitive
>>> button that responds to items in rest of the page)
>>>
>>> So having an almost declaritive style "this button is enabled = fn(x)"
>>> only
>>> works if I know when to re-render that button.
>>>
>>> I seem to be leaving OO behind by having lots of procedural "when x
>>> happens
>>> update a, b and c" rather than a subscribing to events from another
>>> component.
>>>
>>> Using some sort of event model seems to me to improve OO ->
>>> encapsulation ->
>>> reuse. For large trees of components with only tiny parts that need
>>> sending
>>> to the client it also seems more efficient
>>
>> we have a similar use case, where a tabbed panel displays items in
>> different workflow states. To simplify:
>> Tab 1: lists all new items
>> Tab 2: lists all reviewed items
>> Tab 3: lists all closed items
>>
>> For each list item, an ItemPanel is displayed, containing a button that
>> will put the item in the next workflow state. We wanted to reuse this
>> panel in all tabs. In order to be able to properly update models without
>> hard coding page hierarchy into the ItemPanel, we defined an interface
>> ItemStateChangeHandler, that provides the hook
>> onItemStateChange(newState).
>>
>> All tabs implement this interface, and each ItemPanel is created with a
>> reference to the ItemStateChangeHandler that is to be notified when it's
>> about to change state. So when the 'nextState' button is clicked, the
>> handler is notified and will be able to do stuff in the business layer
>> (i.e. persist new state), adjust the list view's model and update the
>> relevant components.
>>
>> Kind of home brew though, so we're very curious as to how others would
>> implement a case like this.
>>
>> Kind regards,
>> Wouter
>>
>> --
>> Wouter Huijnink
>> 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
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Inter-component-events--tf4508127.html#a12899373
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: Inter component events?
Posted by Sam Hough <sa...@redspr.com>.
Maybe something like:
http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-subscriber.html?page=4
No big extra jars...
Would be nice if buttons could just subscribe to some standard set of
messages (e.g. change of focus)
Wouter Huijnink wrote:
>
>
>> I see that it is not such an obvious win here as with fat client but how
>> about another of my use cases:
>> * Large page with small parts being updated by Ajax
>> * Two components sitting long way apart in the tree (context sensitive
>> button that responds to items in rest of the page)
>>
>> So having an almost declaritive style "this button is enabled = fn(x)"
>> only
>> works if I know when to re-render that button.
>>
>> I seem to be leaving OO behind by having lots of procedural "when x
>> happens
>> update a, b and c" rather than a subscribing to events from another
>> component.
>>
>> Using some sort of event model seems to me to improve OO -> encapsulation
>> ->
>> reuse. For large trees of components with only tiny parts that need
>> sending
>> to the client it also seems more efficient
>
> we have a similar use case, where a tabbed panel displays items in
> different workflow states. To simplify:
> Tab 1: lists all new items
> Tab 2: lists all reviewed items
> Tab 3: lists all closed items
>
> For each list item, an ItemPanel is displayed, containing a button that
> will put the item in the next workflow state. We wanted to reuse this
> panel in all tabs. In order to be able to properly update models without
> hard coding page hierarchy into the ItemPanel, we defined an interface
> ItemStateChangeHandler, that provides the hook
> onItemStateChange(newState).
>
> All tabs implement this interface, and each ItemPanel is created with a
> reference to the ItemStateChangeHandler that is to be notified when it's
> about to change state. So when the 'nextState' button is clicked, the
> handler is notified and will be able to do stuff in the business layer
> (i.e. persist new state), adjust the list view's model and update the
> relevant components.
>
> Kind of home brew though, so we're very curious as to how others would
> implement a case like this.
>
> Kind regards,
> Wouter
>
> --
> Wouter Huijnink
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Inter-component-events--tf4508127.html#a12879006
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: Inter component events?
Posted by Wouter Huijnink <w....@func.nl>.
> I see that it is not such an obvious win here as with fat client but how
> about another of my use cases:
> * Large page with small parts being updated by Ajax
> * Two components sitting long way apart in the tree (context sensitive
> button that responds to items in rest of the page)
>
> So having an almost declaritive style "this button is enabled = fn(x)" only
> works if I know when to re-render that button.
>
> I seem to be leaving OO behind by having lots of procedural "when x happens
> update a, b and c" rather than a subscribing to events from another
> component.
>
> Using some sort of event model seems to me to improve OO -> encapsulation ->
> reuse. For large trees of components with only tiny parts that need sending
> to the client it also seems more efficient
we have a similar use case, where a tabbed panel displays items in
different workflow states. To simplify:
Tab 1: lists all new items
Tab 2: lists all reviewed items
Tab 3: lists all closed items
For each list item, an ItemPanel is displayed, containing a button that
will put the item in the next workflow state. We wanted to reuse this
panel in all tabs. In order to be able to properly update models without
hard coding page hierarchy into the ItemPanel, we defined an interface
ItemStateChangeHandler, that provides the hook onItemStateChange(newState).
All tabs implement this interface, and each ItemPanel is created with a
reference to the ItemStateChangeHandler that is to be notified when it's
about to change state. So when the 'nextState' button is clicked, the
handler is notified and will be able to do stuff in the business layer
(i.e. persist new state), adjust the list view's model and update the
relevant components.
Kind of home brew though, so we're very curious as to how others would
implement a case like this.
Kind regards,
Wouter
--
Wouter Huijnink
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: Inter component events?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/25/07, Sam Hough <sa...@redspr.com> wrote:
>
> I see that it is not such an obvious win here as with fat client but how
> about another of my use cases:
> * Large page with small parts being updated by Ajax
> * Two components sitting long way apart in the tree (context sensitive
> button that responds to items in rest of the page)
>
> So having an almost declaritive style "this button is enabled = fn(x)" only
> works if I know when to re-render that button.
>
> I seem to be leaving OO behind by having lots of procedural "when x happens
> update a, b and c" rather than a subscribing to events from another
> component.
>
> Using some sort of event model seems to me to improve OO -> encapsulation ->
> reuse. For large trees of components with only tiny parts that need sending
> to the client it also seems more efficient.
Yeah, if most of what you're doing is Ajax, you need to find a way to
know which components should be updated and my remarks are less
relevant. Still, I think most of it should be communicated via models.
It shouldn't be hard to let your model(object)s implement an observer
pattern and use that to your advantage.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Inter component events?
Posted by Sam Hough <sa...@redspr.com>.
I see that it is not such an obvious win here as with fat client but how
about another of my use cases:
* Large page with small parts being updated by Ajax
* Two components sitting long way apart in the tree (context sensitive
button that responds to items in rest of the page)
So having an almost declaritive style "this button is enabled = fn(x)" only
works if I know when to re-render that button.
I seem to be leaving OO behind by having lots of procedural "when x happens
update a, b and c" rather than a subscribing to events from another
component.
Using some sort of event model seems to me to improve OO -> encapsulation ->
reuse. For large trees of components with only tiny parts that need sending
to the client it also seems more efficient.
btw We are very pleased with our Wicket app as with JS it does nice partial
updates and without JS it chugs along. We only alter the HTML for our modal
window :)
Eelco Hillenius wrote:
>
>> Has anybody used something like javax.swing.ListModel.addListDataListener
>> or
>> java.util.Observable to setup a nice way for components to respond to
>> changes in other components?
>>
>> My use case is that I have a "basket" of items a user has selected. While
>> they are searching/browsing if an item already in the basket appears
>> again I
>> want it to be disabled/greyed out. With hand coding that is a bit ugly
>> and
>> seems like a candidate for some sort listening to changes in another
>> component.
>
> This is where Wicket really works different from a desktop framework
> like Swing though. In swing you would generally push changes to
> observers. In Wicket, you have the request/ response cycle. 'Pulling'
> works better for Wicket, which typically means that you should make
> sure you update relevant state during requests (e.g. via models) so
> that other components use the updated state. So here, you wouldn't
> call setEnabled on the basket via some observer, but rather you would
> do something like override isEnabled and query the relevant state.
>
> 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/Inter-component-events--tf4508127.html#a12875360
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: Inter component events?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Has anybody used something like javax.swing.ListModel.addListDataListener or
> java.util.Observable to setup a nice way for components to respond to
> changes in other components?
>
> My use case is that I have a "basket" of items a user has selected. While
> they are searching/browsing if an item already in the basket appears again I
> want it to be disabled/greyed out. With hand coding that is a bit ugly and
> seems like a candidate for some sort listening to changes in another
> component.
This is where Wicket really works different from a desktop framework
like Swing though. In swing you would generally push changes to
observers. In Wicket, you have the request/ response cycle. 'Pulling'
works better for Wicket, which typically means that you should make
sure you update relevant state during requests (e.g. via models) so
that other components use the updated state. So here, you wouldn't
call setEnabled on the basket via some observer, but rather you would
do something like override isEnabled and query the relevant state.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Inter component events?
Posted by Sam Hough <sa...@redspr.com>.
Or maybe just have a "sortYourSelfOut" method that gets called on all
components after any changes but before the the wicket response life cycle?
Any existing Wicket methods fit this? onBeforeRender? Needs to get called on
_all_ components even for Ajax request...
Sorry for talking to myself.
Sam Hough wrote:
>
> Has anybody used something like javax.swing.ListModel.addListDataListener
> or java.util.Observable to setup a nice way for components to respond to
> changes in other components?
>
> My use case is that I have a "basket" of items a user has selected. While
> they are searching/browsing if an item already in the basket appears again
> I want it to be disabled/greyed out. With hand coding that is a bit ugly
> and seems like a candidate for some sort listening to changes in another
> component.
>
--
View this message in context: http://www.nabble.com/Inter-component-events--tf4508127.html#a12857280
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