Skip to main content

Impossible to implement context-dependent actions with TargetManager?

3 replies [Last post]
czesper
Offline
Joined: 2004-08-17

Hello Mark,

I am working on a GUI frame based on JDNC components to be used for many applications here at CERN. I would like to add a functionality of enabling/disabling TargetableActions depending on a context. For now the context means just a currently focused component, but in future, an action could also be enabled/disabled depending e.g. on the user privileges with some role-based access control model.

Do you plan to add such or similar functionality to the actions framework (I noticed some comments in the TargetManager

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
czesper
Offline
Joined: 2004-08-17

Hello Mark,

Thanks for the answer.
As you mentioned the design notes are mainly focused on XML schema, however I am also interested in your plans concerning the java implementation.

From the proposed methods I prefer the first option for the same reasons – returning array of a particular type is much clearer and more type safe than a collection or an iterator.

Grzegorz

Mark Davidson
Offline
Joined: 2006-02-17

Hi Grzegorz,

I've just added Targetable[] getTargets() to the TargetManager class and checked it into the respository.

I've also added a unit test case for the TargetManager.

I'll try to get a weekly build publicly posted this Friday.

--Mark

Mark Davidson
Offline
Joined: 2006-02-17

Hi Grzegorz,

I'm really glad that you are taking a detailed look at the Actions architecture.

You may want to take a look at my design notes:

https://jdnc.dev.java.net/documentation/design/actions.txt

Some of this information is a little dated and most of it is focused on the end goal of providing a simplified XML schema that represents actions and action containers. There could be a little insight gleaned into my design decisions.

> Hello Mark,
>
> I am working on a GUI frame based on JDNC components
> to be used for many applications here at CERN. I
> would like to add a functionality of
> enabling/disabling TargetableActions depending on a
> context. For now the context means just a currently
> focused component, but in future, an action could
> also be enabled/disabled depending e.g. on the user
> privileges with some role-based access control model.
>
>
> Do you plan to add such or similar functionality to
> the actions framework (I noticed some comments in the
> TargetManager’s source concerning focus changes)?

Yes I do! This is definititely in the long range plans for the Actions architecture. Please see Issue 72 and add your own requirements:

https://jdnc.dev.java.net/issues/show_bug.cgi?id=72

Dynamic enabling/disabling actions represents a significant addition of functionality and I think we may have to break this feature out separately.

>
> Otherwise, to implement this on my own I need access
> to (taken from a javadoc of TargetManager):
> 1) Current Targetable object from TargetManager
> 2) List order of Targetable objects from
> TargetManager
> 3) ActionMap entry of the permanent focus owner
> 4) ActionMap entry of the ancestor hierarchy of the
> permanent focus owner
> 5) ActionMap entry of the current Application
> instance
>
> The problem is that I can access 1, 3, 4 and 5 but I
> can’t access a list of targets from the
> TargetManager. I could subclass TargetManager but
> there is no method setInstance() like in case of
> ActionManager.

The best way to approach this would be to add a public method to a TargetManager that would allow access to the managed target list. Here are a few proposals:

1. public Targetable[] getTargets()

2. public Iterator getTargets()

3. public List getTargets()

The first method is more JavaBeans like and doesn't require casting. The other two collectison methods would be easy since the internal implemention is a java.utilList. In 1.4.x, we would have to cast the elements but we could generify for 1.5.

What would be your preference? I'm leaning toward #1 since it's strongly typed and it's quite clear that we are adding/removing and getting "Targetable" classes.

BTW, Never say "impossible" since software is infinitely malleable. ;-)

--Mark