Community
Participate
Working Groups
Besides the current way DMRs are defined, a DMR should also have a list of segments that can be resolved against a root domain object.
New Gerrit change created: https://git.eclipse.org/r/126619
New Gerrit change created: https://git.eclipse.org/r/127933
New Gerrit change created: https://git.eclipse.org/r/127932
New Gerrit change created: https://git.eclipse.org/r/128044
New Gerrit change created: https://git.eclipse.org/r/128043
New Gerrit change created: https://git.eclipse.org/r/128042
New Gerrit change created: https://git.eclipse.org/r/129860
Gerrit change https://git.eclipse.org/r/126619 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=4821d092c7d38a8dfabdc14e1bc4e0de4959d13b
Gerrit change https://git.eclipse.org/r/126668 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=d80efdd33a7c39ce2bb4d58bb087c7a265eda30a
Gerrit change https://git.eclipse.org/r/127932 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=f1147b3f05cd6633199b71b1b39d1ffc872b6b09
New Gerrit change created: https://git.eclipse.org/r/130018
New Gerrit change created: https://git.eclipse.org/r/130080
Gerrit change https://git.eclipse.org/r/127933 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=736ea70f6e5a95dbe1d06d138a1b794a375fe274
Gerrit change https://git.eclipse.org/r/128042 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=61aeccaee36d5eedef8f05566ad0b0e72c930b63
Gerrit change https://git.eclipse.org/r/128043 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=f2c3f63a24f10806b6453941499255049051a90d
New Gerrit change created: https://git.eclipse.org/r/130981
New Gerrit change created: https://git.eclipse.org/r/130980
Gerrit change https://git.eclipse.org/r/128044 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=dec5e0134246304efcb9ac2ede3b29c648927225
Gerrit change https://git.eclipse.org/r/129860 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=dc4b0d3bb9949d790f568f0a30dbcf663c18bd9e
Gerrit change https://git.eclipse.org/r/130980 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=0bc8277a9bb75a5e6d7c3fb2b5e4ebec4e50022b
New Gerrit change created: https://git.eclipse.org/r/131508
Gerrit change https://git.eclipse.org/r/130981 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=be66ee453f84bf1442008159ddef365fa56325dd
Gerrit change https://git.eclipse.org/r/130018 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=e48bed1b91516a9cab1767178c903699a58433d2
Gerrit change https://git.eclipse.org/r/130080 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=ca5936c4265c5301e78bc5dbb703c369398da6ec
Gerrit change https://git.eclipse.org/r/131508 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=99d100749605779740ead95796e0500740972995
New Gerrit change created: https://git.eclipse.org/r/131669
Gerrit change https://git.eclipse.org/r/131669 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=deeb1e9123eb5004aef8c675a93c20e50b79b036
New Gerrit change created: https://git.eclipse.org/r/132558
Gerrit change https://git.eclipse.org/r/132558 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=51706c8c8f3ae5c021031ca70ffef0d644095fb5
New Gerrit change created: https://git.eclipse.org/r/132719
Gerrit change https://git.eclipse.org/r/132719 was merged to [release_1.19.0]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=bfd1b90481868d868e64c89a7cdc7736198f469e
Domain model references can now also contain a list of segments which is used to resolve a feature in the domain data. EMF Forms support on-the-fly conversion of the old DMRs during runtime. This allows testing EMF Forms's stability using segments without the need to change existing view model files. By default, this conversion is turned OFF. It can be enabled by setting the runtime parameter: -enableSegmentGeneration DMRs with segments do not yet support the full feature set of EMF Forms. Currently open features to implement are tracked in these follow up issues: Bug 542669 - [Segments] Extend view model tooling for segments Bug 542670 - [Segments] Extend view template model tooling for segments Bug 542671 - [Segments] Adapt the view template's DMR selectors to segments Bug 542672 - [Segments] Adapt ViewValidator to segments A final migration of legacy DMRs to segment based DMRs is tracked in Bug 542673 - [Segments] Provide migration with persistence from legacy DMRs to segments
The implementation of domain model reference segments introduces a new way of configuring the path of a domain model reference. To understand the difference, I shortly elaborate on the current domain model reference based approach. Currently, special behavior like using an index on a multi-reference, or defining a table is achieved by using a specialized domain model reference. Thereby, these references typically contain further child references to describe the path to the feature which is treated special. E.g. an index dmr has a prefix dmr, an index and a target dmr. The prefix dmr describes the path to the indexed feature and the target dmr the path from the resolved object of the indexed feature. This approach is quite impractical when multiple special features (e.g. multiple indexings) need to be combined in one domain model reference. Furthermore, the current domain model reference approach is coupled to the structural feature mechanism of EMF. In order to get rid of the problem of cascaded domain model references and move in the direction of a data framework independent approach, we introduce the concept of segments. Thereby, a domain model reference only contains a list of segments. The special behavior is encapsulated in single segments. As a consequence, various special features can be mix and matched in ONE domain model reference by using corresponding segments. Furthermore, the segments don’t have a dependency on EMF anymore. Instead, features are stored based on their name. In context with the root EClass of a domain model reference, they can then be resolved because a feature name is unique for an EClass. Because the change from different domain model references to only a domain model reference that contains various segments is not a trivial migration, we implement a hybrid solution. This allows a gradual migration to the new segment mechanism. This means, current view models can still be used and created as usual. In addition, we introduce a runtime parameter which enables on-the-fly runtime conversion of all domain model references to segments. Thereby, generated segments are not persisted but only used at runtime. As a consequence, enabling the parameter allows risk-free testing of the new mechanism at runtime: If something does not work, the parameter can simply be removed. To make this work, we adapted EMF Forms’s core services to be able to handle the standard domain model references as well as segment based references. If segments are present, the segment based approach is used. The runtime generation of segments can be activated with the program argument: -enableSegmentGeneration Please feel free to activate the segment generation and report any bugs you might encounter.
