Oh, as to why, well as you see ConfigPanel has no real knowledge of
the other panels that are listening to it and does need to call any
methods on them. As a result any number of panels can be registered as
a listener with it, and subsequently swapped out for new ones if
required, without affecting ConfigPanel's code at all. It is up to the
listeners to decide for themselves, individually, what they need to do
when they receive a change event. So there is a very weak association
between ConfigPanel and it's listeners and none at all between the
listeners == low coupling == application components easy to change and
maintain.
On Nov 14, 12:40 pm, gregor <[EMAIL PROTECTED]> wrote:
> GWT has a range of Observer/Observable gadgets off the shelf:
> SourcesxxxxEvents & xxxxListener and xxxListenerCollection utility
> classes. If they don't work quite right for you, it's easy to copy the
> principle and design your own event handling interfaces.
>
> You could have your config Composite implement SourcesChangeEvents,
> for example. Then Comps 1 & 2 can implement ChangeListener and are
> registered with the config Comp. It might work like so:
>
> public class ConfigPanel extends Composite implements
> SourcesChangeEvents {
>
> private ChangeListenerCollection listeners = new
> ChangeListenerCollection();
> private Button saveBtn = new Button("Save",new ClickListener() {
> public void onClick(Widget widget) {
> // you want to send the ConfigPanel itself, not the
> Button!
> // if you just used this it would send the button
> listeners.fireChange(ConfigPanel.this).;
> }
> });
>
> }
>
> public class Comp1 extends Composite implements changeListener {
>
> public void onChange(Widget sender) {
> is (sender instanceof ConfigPanel) {
> ConfigPanel configPanel = (ConfigPanel) sender;
> // call whatever methods you need
> }
>
> }
>
> Don't forget you have to register Comp1 as a lister with ConfigPanel
> somewhere or it won't work, e.g.:
>
> confPanel.addChangeListener(comp1);
>
> And that's about it - goodbye to your static method calls.
>
> regards
> gregor
>
> On Nov 14, 8:45 am, mives29 <[EMAIL PROTECTED]> wrote:
>
> > i meant static methods, not static classes (2nd paragraph 2nd line)
>
> > On Nov 14, 4:43 pm, mives29 <[EMAIL PROTECTED]> wrote:
>
> > > I'd go straight to what I want to do.
>
> > > I have 3 composites in 1 panel, in 1 entrypoint. I have another
> > > entrypoint that pops up when you click a link on the 2nd composite on
> > > the 1st entrypoint. on that second entrypoint you can configure stuff,
> > > that will affect the displayed data on the first entrypoint's
> > > composites. now, im thinking (actually, a friend thought of it, not
> > > me) that the observer pattern is great to use in here, as the 3
> > > composites of the 1st entrypoint will listen to whatever the second
> > > entrypoint configures, then change themselves according to the
> > > specified configurations on the second entrypoint.
>
> > > Currently, I do the changes on the first entrypoint's composites by
> > > calling their static classes (from the second entrypoint's
> > > clicklisteners and stuff) that configures them, which I think is not a
> > > very good practice to implement because it's not easily extensible and
> > > not that good of a design.
>
> > > Now, is it wise to use the observer pattern(personally, I think it
> > > is)? If yes, how do you implement that on GWT 1.5? (we use GWT 1.5.2)
>
> > > thanks in advance
> > > mives29
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
