Operator: User managent | favorite expression | must be exposed as a set of properties

[eparovyshnaya]

Currently node-licked license issuing actively exploits User's favorite expression.

It is presisted as a String emf-property, without a format demands. The property's editor also does not restrict format.

On the other hand, License Issuing process uses this tring directly as Condition expression, which implies 'berlin' format.

Becides, the data hidden in this string will also be of hight demand on a floating license issuing.

Thus, we need to be sure the expression string keeps key-value pairs and be able to operate over them in a unified way.

=========================================================================
The folloiwng work is to be doen in teh scope of this and begotten tasks:

1. User's favorite expression must be exposed for editing as a list of key-value pairs, where keys are not arbitrary, but supplied by all supported Environment implementations.

2. Assemblying and disassemblying processed must be explicitely defined in a single service

3. Personal License Issuing dialog should hide hkey=value pair to berlin expression protocol format coversion

4. ExpressionParsing service must be augmented to writing part to be exploited in a Personal License Issuing dialog.

---

Version: 1.3.0
Ported from bugs.eclipse.org: 566895
Ported from Eclipse Passage Issue 962

[ruspl-afed]

Do you think that we should promote this String to a custom DataType with multiple cardinality or even to an EObject?