Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Any thoughts to having Condtion Objects.
Any thoughts to having Condtion Objects. [message #327080] Wed, 09 April 2008 01:40 Go to next message
Stuart Pond is currently offline Stuart PondFriend
Messages: 27
Registered: July 2009
Junior Member
I have worked with Eclipse ActionSets and now 3.3 Menus, Commands, Handlers.
While I believe that the new 3.3 handlers are much more powerful and
flexible than Actions whe have previously.

However, I still think a more powerful mechanism whould be able to declare
and implement "Condition objects" which simply evaluate true/false. These
condition objects would be tied to classes for implementation and could be
listening to any change in application domain state then change there
true/false state.

Menu Contributions Enablement, Check, or even visiblity could be then tied
to previously defined condition objects, by id.

There could be OOTB define conditions for performing anding/or'ing/not of
conditions so people could construct arbitarily large networks of conditions
to be evaluated.

This would separate the commands handler which performs the commands action
from also have to decide UI considerations like check/uncheck or isEnabled.
Also more of this behavior could be more declarative in the plugin.xml
Re: Any thoughts to having Condtion Objects. [message #327086 is a reply to message #327080] Wed, 09 April 2008 10:50 Go to previous messageGo to next message
Achim Loerke is currently offline Achim LoerkeFriend
Messages: 376
Registered: July 2009
Location: Braunschweig, Germany
Senior Member

On Tue, 8 Apr 2008 21:40:04 -0400, "Stuart Pond" <Stuart.Pond@ugs.com>
wrote:

>I have worked with Eclipse ActionSets and now 3.3 Menus, Commands, Handlers.
>While I believe that the new 3.3 handlers are much more powerful and
>flexible than Actions whe have previously.
>
>However, I still think a more powerful mechanism whould be able to declare
>and implement "Condition objects" which simply evaluate true/false. These
>condition objects would be tied to classes for implementation and could be
>listening to any change in application domain state then change there
>true/false state.
>
>Menu Contributions Enablement, Check, or even visiblity could be then tied
>to previously defined condition objects, by id.
>
>There could be OOTB define conditions for performing anding/or'ing/not of
>conditions so people could construct arbitarily large networks of conditions
>to be evaluated.
>
>This would separate the commands handler which performs the commands action
>from also have to decide UI considerations like check/uncheck or isEnabled.
>Also more of this behavior could be more declarative in the plugin.xml
>
>

If I understand your request correctly you can do all of this using
Activities (at least as of 3.4M6) and the Expression framework. The
Activities have been expanded to support more than just Commands. For
some examples have a look at
http://www.bredex.de/en/rcp-auth/paper.html

The 3rd example (Authorization using Activity) and the paper may be
helpful.


Achim
--
Achim Lörke

Eclipse-Stammtisch in the Braunschweig, Germany area:
http://www.bredex.de/de/career/eclipse.html


Achim Lörke

Re: Any thoughts to having Condtion Objects. [message #327094 is a reply to message #327086] Wed, 09 April 2008 13:33 Go to previous messageGo to next message
Stuart Pond is currently offline Stuart PondFriend
Messages: 27
Registered: July 2009
Junior Member
I read the examples you referenced while somewhat similar it is not quite
what I was thinking.

Condition objects would be more like context objects which are either active
or not. But Conditions typically monitor a very particular part of
application state and translate it to a binary condition on/off. It also
fires notification when its state changes. In this way it is more like a
Finite State Machine. By combining conditions in a declarative fashion you
can come up with very sophisticated and semantically powerful machines that
fundamentally resolve to either true/false. Though they need not be complex
at all either and can be just a single simple condition too.

These results can be then tied (declaratively) to the UI presentation like
Menu/Toolbar contributions which have up to three binary dimensions:
Enablement (Gray/UnGray), Toggle Status (Check/UnCheck), and Visibility.

These conditions could be useful in other parts of the application too. A
condition service could keep a registry of registered conditions and other
parts of code register themselves as listeners to particular conditions and
could then be triggered on state changed of these conditions.

"Achim L
Re: Any thoughts to having Condtion Objects. [message #327098 is a reply to message #327094] Wed, 09 April 2008 14:38 Go to previous messageGo to next message
Achim Loerke is currently offline Achim LoerkeFriend
Messages: 376
Registered: July 2009
Location: Braunschweig, Germany
Senior Member

On Wed, 9 Apr 2008 09:33:03 -0400, "Stuart Pond" <Stuart.Pond@ugs.com>
wrote:

>I read the examples you referenced while somewhat similar it is not quite
>what I was thinking.
>
>Condition objects would be more like context objects which are either active
>or not. But Conditions typically monitor a very particular part of
>application state and translate it to a binary condition on/off. It also
>fires notification when its state changes. In this way it is more like a
>Finite State Machine. By combining conditions in a declarative fashion you
>can come up with very sophisticated and semantically powerful machines that
>fundamentally resolve to either true/false. Though they need not be complex
>at all either and can be just a single simple condition too.
>
>These results can be then tied (declaratively) to the UI presentation like
>Menu/Toolbar contributions which have up to three binary dimensions:
>Enablement (Gray/UnGray), Toggle Status (Check/UnCheck), and Visibility.
>
>These conditions could be useful in other parts of the application too. A
>condition service could keep a registry of registered conditions and other
>parts of code register themselves as listeners to particular conditions and
>could then be triggered on state changed of these conditions.
>

The Expression framework does allow you to bind (registered) variables
to Activities. You may change this variables in your program code and
notify interested parties. It's not done by introducing Condition
objects, but the result looks the same to me.

This code is available in the platform (at least for Commands, for
other things like Views, Perspectives etc. with 3.4). You may open an
enhancement request against RCP in Bugzilla, but since I know much
work was done by the committers on the Activities solution I doubt
that they will add a very similar construct.




Achim
--
Achim Lörke

Eclipse-Stammtisch in the Braunschweig, Germany area:
http://www.bredex.de/de/career/eclipse.html


Achim Lörke

Re: Any thoughts to having Condtion Objects. [message #327105 is a reply to message #327080] Wed, 09 April 2008 19:22 Go to previous message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

It's an interesting thought ... it would lean much more towards
event-driven over request-driven UI state. For example, how important
is it to enable/disable a menu item until that menu is about to be shown
(not very). Tool items are different, of course.

There are tools to implement some of your condition objects in the core
expressions+IEvaluationService.

The IEvaluationService allows you to register an
org.eclipse.jface.util.IPropertyChangeListener against a core
expression. That expression cares about variables (from event driven
source providers) and property testers (implementations that take the
object in scope + some args and return true or false). The
IEvaluationService allows you to monitor events outside the source
provider variables and request that a property (a la property tester) be
re-evaluated.

Any change from between TRUE and FALSE will notify your property change
listener.

A scaled back, internal version of the IEvaluationService is what drives
declarative handler enablement and menu visibility in 3.3. In 3.4 it is
public API, and drives handler activation and optionally activity
enablement as well.

Once you have something that will fire events when its TRUE/FALSE value
changes, then you need to wire it up (it's already wired up to
declarative handler enablement and menu contribution visibility).

There are other ways to implement it as well, of course,

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm


Previous Topic:Context Sensitive help on linux
Next Topic:Overriding an action created in createdActions() from the AbstractTextEditor class.
Goto Forum:
  


Current Time: Sat Nov 09 03:31:42 GMT 2024

Powered by FUDForum. Page generated in 0.03602 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top