| Summary: | Support simpler EL check of a value against a set of expected values | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Konstantin Komissarchik <konstantin> |
| Component: | Sapphire | Assignee: | Konstantin Komissarchik <konstantin> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ling.hao |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Enhancement implemented. Updated the EL documentation and the what's new doc for 0.3 release. Unit tests in TestExpr0005 and TestExpr0006. Example of usage in IIfThenElseGallery class of the gallery sample. Verified in gallery sample, unit test and coherence test case. |
Consider the case where a property holds an enum and you need to check to see if the property holds one of three enum values. You can write an expression like this one: ${ ShapeType == 'TRIANGLE' || ShapeType == 'RECTANGLE' || ShapeType == 'SQUARE' } But that's quite verbose, especially as the number of items to check goes higher. There can also be a problem if LHS of the comparison is an expression rather than a simple property access. Using this pattern would re-evaluate the expression multiple times. We need something equivalent to SQL IN operator. We should be able to write the above expression like so: ${ ShapeType IN List( 'TRIANGLE', 'RECTANGLE', 'SQUARE' ) } To do this we need two things: (a) List function that can turn an arbitrary number of operands into a list and (b) IN operator.