Community
Participate
Working Groups
Created attachment 125236 [details] Patch that adds support for additional count expressions. Build ID: M20080911-1700 Steps To Reproduce: 1. Attempt to use a more advanced count expression in a plugin. More information: Currently count expressions are very limited, it would be very useful to have more options. The particular use case that I have run into is in a graphical editing tool where I would like to activate commands when 2 or more objects are selected in the editor (in this case the commands are to align objects, which only makes sense if there are multiple objects selected).
I should note that the patch also includes a line (size = size.trim() at -58,6 +70,7) that makes count expressions resistant to leading and trailing whitespace, I can create a separate issue & patch for that fix if you would prefer things to be entered that way.
Created attachment 125376 [details] JUnit tests for the CountExpression class. I forgot to add this file when I created the issue - here are some unit tests for the class (both new and existing functionality). I couldn't find a document explaining how the unit tests should be packages up (e.g. in the same plug-in or in a separate test plug-in) but if somebody could point me at such a doc I'd be happy to apply it's rules. In the meantime here is the raw test class, it's in the correct package already.
Wow, thank you Ian. Some comments: 1) Markus can correct me if I'm wrong, but like most low-level plugins we might not be able to consume Pattern code (1.4 lib) in order to support Foundation 1.0/CDC 1.0 If this is the case then we could potentially support <num>+ to mean num or more and <num>- to mean up to and including <num> 2) The test can be added as a patch on org.eclipse.core.exressions.tests and added to the automated test run by adding suite.addTest(CountExpressionTest.suite()); to org.eclipse.core.internal.expressions.tests.AllTests 3) these 2 bundles are <J2SE-1.5 so the annotations should be removed. PW
(In reply to comment #3) > 1) Markus can correct me if I'm wrong, but like most low-level plugins we might > not be able to consume Pattern code (1.4 lib) in order to support Foundation > 1.0/CDC 1.0 Yes, and as long as dependencies such as org.eclipse.ui.workbench also stay on Foundation 1.0, we should not change that. > If this is the case then we could potentially support <num>+ to mean num or > more and <num>- to mean up to and including <num> I find <num>- hard to understand (it also looks like an open range, starting with <num>, but that would be the same as <num>+) I agree though that ">n" and "<n" can be interesting, but we should keep this simple: - no trim() - two additional patterns are enough: "<n" and ">n", where n is an integer Furthermore, the new patterns need to be documented in /org.eclipse.core.expressions/schema/expressionLanguage.exsd Tests should go into /org.eclipse.core.expressions.tests/src/org/eclipse/core/internal/expressions/tests/ExpressionTests.java Please use Eclipse to create a single patch with all files (on the second page of the Create Patch wizard, select Patch Root > Workspace).
OK, I'll update the code to make it CDC friendly and provide an updated patch with the tests in the correct location (thanks for the pointer, BTW). It may take me a few days to get around to it, probably by the weekend.
(In reply to comment #5) > OK, I'll update the code to make it CDC friendly and provide an updated patch > with the tests in the correct location (thanks for the pointer, BTW). Hi Ian, just a prod to note that this is the last week for new "API", if you would like this to go in we would need something before the end of the week. PW
Created attachment 127320 [details] CDC-1.0 compliant workspace patch OK, I've made the following changes to the patch: 1. removed the call to trim. 2. removed the >= and <= options completely. 3. rewritten > and < to no longer use patterns (see below). 4. documented the new patterns in expressionLanguage.exsd. 5. added the unit tests and included these (it's now a workspace patch). for the greater than and less than expressions I've gone with '-' as the signifying character based on the comments from Markus. So (from the docs): <dt>-<i>N</i>)</dt> <dd>less than <i>N</i> elements</dd> <dt>(<i>N</i>-</dt> <dd>greater than <i>N</i> elements</dd> I based the parentheses in the pattern (to indicate exclusivity in the range of allowed numbers) on the same contruct that it is used in OSGi bundle manifests to indicate version ranges. This leaves us with the option of supporting less than or equal to with, for example, "-3]" in future. I have left the tests for this in the file but commented them out My thinking being that using a hyphen for both patterns is that it looks like a number range, an alternative here could be 2 or 3 periods (like a range operator from python or an ellipsis, respectively). These characters also have the advantage that they do not need to be escaped in the XML, which was a problem with using the otherwise more intuitive "<" and ">" characters. Cheers, Ian.
(In reply to comment #7) > Created an attachment (id=127320) [details] > CDC-1.0 compliant workspace patch I'm fine with it (and can add a simple hook up to AllTests, suite.addTest(CountExpressionTest.suite()) ). Markus, if you have no objections I think this can go in. PW
(In reply to comment #7) > Created an attachment (id=127320) [details] > CDC-1.0 compliant workspace patch Released to HEAD >20090305 PW
In I20090310-0100 PW
