|
Re: Any thoughts to having Condtion Objects. [message #327086 is a reply to message #327080] |
Wed, 09 April 2008 10:50 |
|
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 #327098 is a reply to message #327094] |
Wed, 09 April 2008 14:38 |
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03602 seconds