DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report

Commands Part 2: Selection and Enablement of IHandlers

Prakash  user avatar by
Prakash
·
Jan. 08, 09 · Interview
Like (0)
Save
Tweet
Share
10.50K Views

Join the DZone community and get the full member experience.

Join For Free

In the last tip, we saw that a Handler can be declared separately from a Command. This enables for multiple handler declarations for the same command. We can also customize when a handler is active and visible, thru plugin.xml itself. A handler that doesn't have any of these conditions is called as "default handler". When no other handler is associated with a command in a particular context, then the default handler will be the handler that gets executed. Remember, at any given point of time, there is at most only one handler is associated with a command. Lets have a look into how a particular handler is selected for a given context.

A handler can be specified with activeWhen condition using the expression language. Say for our command, we have two different handlers. One should be active when the current selection is an IFile and the other should be active when the current selection is IFolder. The expression for these would look like:

<handler 
class="com.eclipse_tips.commads.SomeCommandHandler1"
commandId="com.eclipse-tips.commands.someCommand">
<activeWhen>
<with
variable="selection">
<iterate
operator="or">
<instanceof
value="org.eclipse.core.resources.IFile">
</instanceof>
</iterate>
</with>
</activeWhen>
</handler>
<handler
class="com.eclipse_tips.commads.SomeCommandHandler2"
commandId="com.eclipse-tips.commands.someCommand">
<activeWhen>
<with
variable="selection">
<iterate
operator="or">
<instanceof
value="org.eclipse.core.resources.IFolder">
</instanceof>
</iterate>
</with>
</activeWhen>
</handler>

 

I'll save the explanation for the expression language for a separate tip, but for now a short one line desc: the first handler will be enabled when the selection current contains at least one IFile and the second handler will be enabled when the selection contains at least one IFolder. This raises to two questions.

1) What if the selection is just an IProject?

In this case, as none of the handlers are eligible, the command is disabled. This is where the default handler, if you have provided one, would be associated with the command (and the command will be enabled).

2) What if the selection contains both IFile and IFolder?

Now both the handlers are equally qualified to handle the command. But since the framework cannot pick one randomly the command is simply disabled. Even if you have provided a default handler, it won't be associated with the command, because the other two handlers are more specific than the default one.

How is the "specificness" of a handler is defined? It depends on the conditions that you give in the activeWhen expression. The order is defined in the ISources class. You can go thru the complete set there, to get a glimpse of the most commonly used ones, the order from least specific to most specific is like this:

  • Active Context (activeContexts)
  • Active Actions Sets (activeActionSets)
  • Active Shell (activeShell)
  • Active Workbench Window (activeWorkbenchWindow)
  • Active Editor Id (activeEditorId)
  • Active Part Id (activePartId)
  • Current Selection (selection)

If a handler has activeWhen defined with active context and the other one with current selection, the second one will be selected as the selection is more specific than the active context. The activeWhen for all the handlers are evaluated and the one that returns true for the most specific condition is selected. When two handlers return true for the available most specific condition (like the selection having both IFile & IFolder in our case), no handler will be associated with the command.

All these things are done without even loading your handler in the memory. Even without loading your plugin! 

In the previous tip, we saw how a handler is selected with the activeWhen expression, when more than one handler is declared. Now assuming a handler is selected, whether to enable the command or not, is determined by the enabledWhen expression.

In our previous example, we saw the handler that is active when the selection at least contained one IFile. Now lets we want to enable it only when the total count of the selection is 2. We can specify it as:

<handler 
class="com.eclipse_tips.commads.SomeCommandHandler1"
commandId="com.eclipse-tips.commands.someCommand">
<activeWhen>
<with
variable="selection">
<iterate
operator="or">
<instanceof
value="org.eclipse.core.resources.IFile">
</instanceof>
</iterate>
</with>
</activeWhen>
<enabledWhen>
<with
variable="selection">
<count
value="2">
</count>
</with>
</enabledWhen>
</handler>

 

So the handler will be active and associated with the command, if the selection contains at least one IFile. Still the command will be enabled only if selection has exactly 2 elements. activeWhen and enabledWhen are similar - with respective to the expression language and lazy loading of the plugin until the command is executed. But there is small difference - your handler might be loaded iff the enabledWhen expression returns true and your plugin is already loaded. The enablement algo works this way:

  • No enabledWhen specified, plugin is not loaded - command is enabled
  • No enabledWhen specified, but plugin is loaded - consult handler.isEnabled() and set command accordingly
  • enabledWhen specified, returns false, command is disabled (no matter plugin is loaded or not)
  • enabledWhen specified, returns true, plugin is not loaded - command is enabled
  • enabledWhen specified, returns true, plugin is loaded - consult handler.isEnabled() and set command accordingly

So far we saw commands, handlers and their enablements. But what about generalizing a command? That can be done by adding parameters for a command. And that would be the next tip in this series.

From http://blog.eclipse-tips.com

Command (computing)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Detecting Network Anomalies Using Apache Spark
  • How to Use Buildpacks to Build Java Containers
  • 4 Best dApp Frameworks for First-Time Ethereum Developers
  • What Is JavaScript Slice? Practical Examples and Guide

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: