[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [henshin-dev] Proposal to remove direct creation of edges
|
Heyhey,
I discussed the issue with Stefan and we came up with the following
solution. The necessity to force connected edges arose from the
assumtion that multiRules have to include the complete kernel. The
design rationale for AmalgamationUnits was based on the easy
implementation of the application logic by means of RuleApplications.
This can not be transfered to nested amalgamation, which requires a more
laborious implementation. Therefore the discussion of editor features
regarding the automatic synchronization of multiRules is moot. The
editor continues to allow creation of unconnected and untyped Edges.
Since there has been no feedback whether or not somebody is implementing
the interpretation of nested amalgamation, I will start this now.
@Enrico: Please let me know if you have already begun with the
implementation!
Some thoughts and open questions. Please comment as needed:
- As mentioned above the multiRules have to contain only those nodes
from the kernel which are required to define the connection between the
graphs (as it is with NestedConditions).
- How should injectiveMatching and checkDangling be handeled? Should the
kernel define this transitive for all multiRules?
- In contrast to AmalgamationUnits injective matching has to prevent
overlapping matches of multiRules. So mutually impeding or self-impeding
multiRules are allowed.
- There are several strategies for unfolding a rule scheme resulting in
different first matches. But as it is with rules, the first match
counts. Are there any preferred strategies like depth-first or
breadth-first?
- Are we planning to integrate scheme formulas as proposed by Christian?
( http://journal.ub.tu-berlin.de/eceasst/article/view/260 ) I think,
current implementation should at least leave this option open.
Regards,
Gregor
Am 11.12.2011 19:35, schrieb Christian Krause:
Hi all,
the EMF editors basically follow a "free editing" paradigm, with
low-level and simple editing operations. What Gregor is planning is
more like syntax-directed editing with complex but very restrictive
editing operations.
I think, we should not remove the basic editing operations of the EMF
editor. I think it is nice to have the advanced editing operations,
but users should not be forced to use them. EMF users simply expect to
have the basic editing operations. And it *is* allowed to produce
inconsistent models during the editing. The means for checking
consistency is validation (as e.g. in the GMF model editors).
Cheers,
Christian
On 12/11/2011 01:38 PM, Gregor Bonifer wrote:
Hi,
the problem does not concern the interpretation of the transformation
models, but the creation process in the tree-based editor. I think I
should illustrate this in more detail:
Given a rule (here called kernel) with a multiRule. The multiRule has
to mirror the structure of the kernel. I implemented a propagation
mechanism for the creation of AddCommand. If a GraphElement is added
to a rule, a corresponding element is created in every multiRule(for
nodes this includes mapping). I also changed the creation of
SetCommand for Nodes and Edges so they propagate the changes into the
multiRules, e.g setting the type of a node will set the type of all
dependent nodes in the multiRules. A node can only be edited in its
defining context. This means that a node may only be edited if it is
not dependent(but there may be nodes depending on it). To visualize
this distictions I regenerated the edit-code to add IItemColorProviders.
The same should be done for edges. To update dependent edges it is
necessary to resolve them via the multiMapping of there nodes. This
might also be done without nodes, but, as I said, this is a guessing
game, which becomes a problem when one changes the ordering of a
multiRule's edges. More importantly it is not possible to determine
whether or not a multiRule's edge is dependent if it has no nodes.
Assuming a kernel with only a single edge and a multiRule with two
edges, one can see that there is no way to determine which of the
multiRule's edges may be edited and which is the dependent one.
This can easily be avoided if edges are created only in ways that
already define the source and target.
I think creating edges without nodes is really not a neccessary
feature. I even think that it should be considered a bad habit, since
in theory there are no edges without nodes (i.e edges with undefined
src/trg functions). I can also imagine situations where one might
want this. But I can neither imagine a goal whose feasibility relies
on this, nor can I imagine a scenario which might become more
cumbersome without this possibility.
Regards,
Gregor
P.S.: Perhaps we should think about generating another editor(incl.
edit) which will be kept unchanged, to provide lowest-level editing.
Am 10.12.2011 21:55, schrieb Riegerf@xxxxxxxxxxxxxxxxxxxxxxx:
Hi Gregor,
Quoting Gregor Bonifer <gregor.bonifer@xxxxxx>:
If an edge is created directly in a graph it has neither source nor
target. Therefore identifying the dependent edges of a kernel edge
becomes kind of a guessing game.
Is this a problem? I.e. will verifying the model create an error if
edges are not set correctly by the user or will the interpreter just
(mysteriously) not work correctly (although the model passed the
verification)?
I would like to exclude edges from the "Create Child" and "Create
Sibling" menu. Edges should always be created by commands which
imply setting the source and target references [...]
Are there any objections?
I strongly object; removing functionality is not a good idea at all,
especially when it comes to these rather primitive operations. I can
imagine situations where one might to create an edge before its
target Node is created, which would be made impossible.
Of course, the user will have a more comfortable editing experience
without needing to specify additional information if she chooses the
advanced editing functions.
Felix
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
