Add ActionListener to an Action

java-programmer, Add ActionListener to an Action
Okay so Action is fine for centralising event handling for multiple controls
of the same function. But I want to add a plain ActionListener for this
event. Seems reasonable. If I was just using ActionListeners I would add
as many as I like to a component. And they'd all be notified, but if I use
Action then I need to add the ActionListener to the Action, I can't.
Do I really need to get my subclassed AbstractAction to manage
ActionListeners and propagate the ActionEvent by calling
super.actionPerformed ?
Is there a better way? Other than abusing PropertyChangeListener ?

--
Mike W

java-programmer >> Add ActionListener to an Action VisionSet schrieb:
> Okay so Action is fine for centralising event handling for multiple controls
> of the same function. But I want to add a plain ActionListener for this
> event. Seems reasonable. If I was just using ActionListeners I would add
> as many as I like to a component. And they'd all be notified, but if I use
> Action then I need to add the ActionListener to the Action, I can't.

Why?

> Do I really need to get my subclassed AbstractAction to manage
> ActionListeners and propagate the ActionEvent by calling
> super.actionPerformed ?
> Is there a better way? Other than abusing PropertyChangeListener ?
>

What prevents you from adding an ActionListener to your component?

Bye
Michael

java-programmer >> Add ActionListener to an Action
"Michael Rauscher" <email***@***.com> wrote in message
news:c9r17c$5kb$06$email***@***.com...
> VisionSet schrieb:
> > Okay so Action is fine for centralising event handling for multiple
controls
> > of the same function. But I want to add a plain ActionListener for this
> > event. Seems reasonable. If I was just using ActionListeners I would
add
> > as many as I like to a component. And they'd all be notified, but if I
use
> > Action then I need to add the ActionListener to the Action, I can't.
>
> Why?
>
> > Do I really need to get my subclassed AbstractAction to manage
> > ActionListeners and propagate the ActionEvent by calling
> > super.actionPerformed ?
> > Is there a better way? Other than abusing PropertyChangeListener ?
> >
>
> What prevents you from adding an ActionListener to your component?
>

Nothing, but I'd have to add it to all the components that share the Action.
Sort of defeats the centralised nature that is the goal of Action.

I think I'll have to explicitly manage ActionListeners within my Action
subclass.

java-programmer >> Add ActionListener to an Action VisionSet schrieb:
> "Michael Rauscher" <email***@***.com> wrote in message
[...]
>>What prevents you from adding an ActionListener to your component?
>>
>
>
> Nothing, but I'd have to add it to all the components that share the Action.
> Sort of defeats the centralised nature that is the goal of Action.
>
> I think I'll have to explicitly manage ActionListeners within my Action
> subclass.

Could you write the purpose of this? Perhaps, there's another solution.

Bye
Michael

java-programmer >> Add ActionListener to an Action

"Michael Rauscher" <email***@***.com> wrote in message
news:c9r4lv$b39$00$email***@***.com...
> VisionSet schrieb:
> > "Michael Rauscher" <email***@***.com> wrote in message
> [...]
> >>What prevents you from adding an ActionListener to your component?
> >>
> >
> >
> > Nothing, but I'd have to add it to all the components that share the
Action.
> > Sort of defeats the centralised nature that is the goal of Action.
> >
> > I think I'll have to explicitly manage ActionListeners within my Action
> > subclass.
>
> Could you write the purpose of this? Perhaps, there's another solution.
>

It's an exercise in decoupling. My Controller class does model specific
actions, my View does view specific actions. I have a separate listener in
each.
I could just call the controller from the view, but I'm keeping it more
event driven.

java-programmer >> Add ActionListener to an Action VisionSet schrieb:
> "Michael Rauscher" <email***@***.com> wrote in message
> news:c9r4lv$b39$00$email***@***.com...
>
>>VisionSet schrieb:
>>
>>>"Michael Rauscher" <email***@***.com> wrote in message
>>
>>[...]
>>
>>>>What prevents you from adding an ActionListener to your component?
>>>>
>>>
>>>
>>>Nothing, but I'd have to add it to all the components that share the
>
> Action.
>
>>>Sort of defeats the centralised nature that is the goal of Action.
>>>
>>>I think I'll have to explicitly manage ActionListeners within my Action
>>>subclass.
>>
>>Could you write the purpose of this? Perhaps, there's another solution.
>>
>
>
> It's an exercise in decoupling. My Controller class does model specific
> actions, my View does view specific actions. I have a separate listener in
> each.
> I could just call the controller from the view, but I'm keeping it more
> event driven.

As an Action is a controller, I assume you want to "decouple" the view
from the controller in that way that the view doesn't need to know what
specific controller is used, right?

So, I further assume you have something like an ActionFactory that
always uses the same Action class to generate the instances, something
like a generic action class, right?

If so, the big question is: do you want to have more than one controller
per action at a time?

Bye
Michael

java-programmer >> Add ActionListener to an Action Subclass the component as a nested class - make it its own actionlistener -
add a "click" method for the component that calls its own actionperformed
metthod.

kinda reminds you of vb doing it that way - roughly goes this way:

Class YourClass{
// stuff you want in your class

class GoButton extends JButton implements ActionListener{

public GoButton(){
super("Go");
}

public void click(){
//code to do what you want
}

public void ActionPerformed(ActionEvent e){
click();
}
}
}

"VisionSet" <email***@***.com> wrote in message
news:Hd8wc.1213$Oc1.175@newsfe4-gui...
>
> Okay so Action is fine for centralising event handling for multiple
controls
> of the same function. But I want to add a plain ActionListener for this
> event. Seems reasonable. If I was just using ActionListeners I would add
> as many as I like to a component. And they'd all be notified, but if I
use
> Action then I need to add the ActionListener to the Action, I can't.
> Do I really need to get my subclassed AbstractAction to manage
> ActionListeners and propagate the ActionEvent by calling
> super.actionPerformed ?
> Is there a better way? Other than abusing PropertyChangeListener ?
>
> --
> Mike W
>
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.690 / Virus Database: 451 - Release Date: 5/22/2004

java-programmer >> Add ActionListener to an Action

"Michael Rauscher" <email***@***.com> wrote in message
news:c9r6rk$ce1$00$email***@***.com...

> >>>
> >>>I think I'll have to explicitly manage ActionListeners within my Action
> >>>subclass.
> >>
> >>Could you write the purpose of this? Perhaps, there's another solution.
> >
> > It's an exercise in decoupling. My Controller class does model specific
> > actions, my View does view specific actions. I have a separate listener
in
> > each.
> > I could just call the controller from the view, but I'm keeping it more
> > event driven.
>
> As an Action is a controller, I assume you want to "decouple" the view
> from the controller in that way that the view doesn't need to know what
> specific controller is used, right?

Well there are controllers and there are controllers. I hold with the view
that there are superficial controllers that just deal with view concerns,
enabling, disabling, configuring etc. And there are Model/View controllers
that bridge between view and model. My Action objects are all in the view.
They have view type responsibilities eg icons, display text... But
obviously a fair few need to trigger model updates. I thought a fair way to
do this was to propagate the action event to the MVController, for it to
deal with it.

>
> So, I further assume you have something like an ActionFactory that
> always uses the same Action class to generate the instances, something
> like a generic action class, right?

I suppose the Action could live in the MVController in this way. Since the
view would instantiate it and pass it the view components it needs, icons,
text etc.

java-programmer >> Add ActionListener to an Action VisionSet schrieb:
>
> Well there are controllers and there are controllers. I hold with the view

Yes. The Action objects which deal with the model (or another
controller) are MVC controllers, too.

> that there are superficial controllers that just deal with view concerns,
> enabling, disabling, configuring etc. And there are Model/View controllers
> that bridge between view and model. My Action objects are all in the view.
> They have view type responsibilities eg icons, display text... But
> obviously a fair few need to trigger model updates. I thought a fair way to
> do this was to propagate the action event to the MVController, for it to
> deal with it.

You don't need to propagate the event to the MVController. Please post
some code, that would make life much easier :-)

Bye
Michael

java-programmer >> Add ActionListener to an Action

VisionSet wrote:

>
> Well there are controllers and there are controllers. I hold with the view
> that there are superficial controllers that just deal with view concerns,
> enabling, disabling, configuring etc. And there are Model/View controllers
> that bridge between view and model. My Action objects are all in the view.
> They have view type responsibilities eg icons, display text... But
> obviously a fair few need to trigger model updates. I thought a fair way to
> do this was to propagate the action event to the MVController, for it to
> deal with it.
>

Do you know the (first and until now only glimpse on it) Action
Framework at http://www.javadesktop.org/articles/actions/index.html?

Part of it is about decoupling: the DelegateAction provides all the view
related properties and delegates the action event to an actionListener.
It then implements this actionListener via an EventHandlerProxy as a
callback to any method you choose in any handler you want. I'm quite
happy with it (using it in my FormBuilder <g>)

The DelegateAction is implemented as unicast, but if you really need it,
you could change to multicast at not much cost. But do you really need
it? Personally, I rarely have the necessity to have a 1:n relationship
between "view action" and "model action", it's mostly 1:1 - but maybe I
misunderstood you.

Have a nice weekend
Jeanette

java-programmer >> Add ActionListener to an Action "Michael Rauscher" <email***@***.com> wrote in message
news:c9se4n$i3l$03$email***@***.com...

>
> You don't need to propagate the event to the MVController. Please post
> some code, that would make life much easier :-)
>

Just bashed this in, hope there's enough here to give you the gist.

class Controller {
private View view;
private Model model;
private ActionListener xListener = new ActionListener() {
public void actionPerformed(ActionEvent e) {
// do Model stuff
}
}

private ActionListener yListener ...

Controller(View v, Model m) {
this.view = v; this.model= m;
view.getActionX().addActionListener(xListener);
view.getActionY().addActionListener(yListener);
}
}

class View {

private Controller controller; // It's here but I don't use it. Could
just as well be a singleton.

View() {
controller = new Controller(this, new Model());
}

abstract class MyAction() extends AbstractAction {
ActionListener al;
void setActionListener(ActionListener l) {al = l;}
public void actionPerformed(ActionEvent e) {
al.actionPerformed(e);
}
}

private Action xAction = new MyAction() {
public void actionPerformed(ActionEvent e) {
// do view stuff
super.actionPerformed(e);
}
}

}

java-programmer >> Add ActionListener to an Action
"Kleopatra" <email***@***.com> wrote in message
news:email***@***.com...
>
>
> VisionSet wrote:
>
> >
> > Well there are controllers and there are controllers. I hold with the
view
> > that there are superficial controllers that just deal with view
concerns,
> > enabling, disabling, configuring etc. And there are Model/View
controllers
> > that bridge between view and model. My Action objects are all in the
view.
> > They have view type responsibilities eg icons, display text... But
> > obviously a fair few need to trigger model updates. I thought a fair
way to
> > do this was to propagate the action event to the MVController, for it to
> > deal with it.
> >
>
> Do you know the (first and until now only glimpse on it) Action
> Framework at http://www.javadesktop.org/articles/actions/index.html?
>
> Part of it is about decoupling: the DelegateAction provides all the view
> related properties and delegates the action event to an actionListener.
> It then implements this actionListener via an EventHandlerProxy as a
> callback to any method you choose in any handler you want. I'm quite
> happy with it (using it in my FormBuilder <g>)
>
> The DelegateAction is implemented as unicast, but if you really need it,
> you could change to multicast at not much cost. But do you really need
> it? Personally, I rarely have the necessity to have a 1:n relationship
> between "view action" and "model action", it's mostly 1:1 - but maybe I
> misunderstood you.
>

That all sounds reassuring, exactly the sort of thing I'm dreaming up.
I don't need a framework, I'd just like reasurrance that my design/idea
isn't pants (that's poor if you're outside blighty :-)

java-programmer >> Add ActionListener to an Action VisionSet schrieb:
> "Michael Rauscher" <email***@***.com> wrote in message
> news:c9se4n$i3l$03$email***@***.com...
>
>
>>You don't need to propagate the event to the MVController. Please post
>>some code, that would make life much easier :-)
>>
>
>
> Just bashed this in, hope there's enough here to give you the gist.

As you've tightly coupled Controller and View, decoupling events is
superfluous. Furthermore your approach is very inflexible and not
object-oriented. I'll show you that.

I've already written that an action is a controller. So, what you've
done within your Action#actionPerformed is encoding the original message
(the action - not the action object) with an object and reach this
object (ActionEvent in this case) further to another controller. And
you'd like to use the same controller in all actions. This makes the
message Controller#actionPerformed ambiguos.

This in turn leads into if-then statements. These are hard to maintain,
error-prone, inflexible and non-object-oriented. Within your Controller
you have to decode the object in order to get the original message (the
action). Apart from loss of perfomance, this violates the
Open-Closed-Principle (open for extension, but closed for modification).
That is because you have to change the actionPerformed Method every time
you want to add an action.

I'll show you an example of how I'd do that (without interfaces to not
complicate things - although these were better):

class Controller {
private Model model;

public Controller( Model m ) {
model = m;
}

// example
public setName( String name ) {
// do Model stuff
}
}

class View {
private Controller controller;
private Model model;
private JTextField name; // example

private Action xAction = new AbstractAction() {
public void actionPerformed( ActionEvent e ) {
controller.setName( name.getText() ); // example
}
}

// standard model, standard controller
public View() {
model = new Model();
controller = new Controller(model);
}

// decoupling: user defined controller, user-defined model
public View( Controller c, Model m ) {
controller = c;
model = m;
}

// ....
}

Relating the controller, adding an action ist just adding a new method.
You could further decouple view and controller by using interfaces.

Bye
Michael

java-programmer >> Add ActionListener to an Action
"Michael Rauscher" <email***@***.com> wrote in message
news:c9uudt$b3j$04$email***@***.com...

> I'll show you an example of how I'd do that (without interfaces to not
> complicate things - although these were better):
>
> class Controller {
> private Model model;
>
> public Controller( Model m ) {
> model = m;
> }
>
> // example
> public setName( String name ) {
> // do Model stuff
> }
> }
>
> class View {
> private Controller controller;
> private Model model;
> private JTextField name; // example
>
> private Action xAction = new AbstractAction() {
> public void actionPerformed( ActionEvent e ) {
> controller.setName( name.getText() ); // example
> }
> }
>
> // standard model, standard controller
> public View() {
> model = new Model();
> controller = new Controller(model);
> }
>
> // decoupling: user defined controller, user-defined model
> public View( Controller c, Model m ) {
> controller = c;
> model = m;
> }
>
> // ....
> }
>
> Relating the controller, adding an action ist just adding a new method.
> You could further decouple view and controller by using interfaces.
>

Mmmm, when you stand back and think design-design rather than evolve-design.
Your solution does seem obvious. Thanks, exploring less than brilliant
alternatives always makes the better approaches more understandable and
pertinent.

I hadn't got to any if/else issues, if that had got excessive it would have
set alarm bells ringing. The app is quite simple, it may never have
regressed that far.

Thanks again.