Re: [henshin-dev] Proposal to remove direct creation of edges

[Christian Krause <henshin.ck@xxxxxxxxx>]

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