|
Hi Claudia,
your extension seems useful also for other applications and I
think it is a good idea to incorporate it into our development
version. Since we changed the API and the internal structure of
the interpreter (e.g. the matching plug-in was merged into the
interpreter plug-in), it would be more helpful if you can send us
the added or changed Java files. Then I can see what's the best
way to integrate them.
Cheers,
Christian
On 07/12/2012 04:40 PM, Claudia Ermel wrote:
Dear
Gregor and all,
as discussed last Tuesday, we need a patch for henshin.matching
and henshin.interpreter that allows us in our new triple graph
grammar editor to apply rules according to certain source
consistency conditions.
Using the patch, these conditions can be incorporated in a special
UserConstraint class where we implement the additional checks that
have to be performed for matching.
In our particular case, we check a boolean attribute
"isTranslated" of a rule node that, if true, must be mapped to a
graph node only if this graph node has been translated before;
(and the other way round: a "false"-tagged rule node must be
matched only to a graph node that has NOT YET been translated --
we check this by looking up certain tables where we store ids of
translated elements).
We cannot model this by an equally-bound "isTranslated" attributes
in the instance model because the instance model (and its EMF
model) must not be extended by new attribute (types); the
"isTranslated" attribute serves only for rule application
purposes, but does not belong to the model.
Moreover, it does NOT help us to check only if the objects are in
the "used objects" list of the matchfinder, because there may be
objects that have been used by the rule before
("used_object=true") but should be used again by the next rule
since the matches of both rules may well overlap in these objects.
The "used_object" value alone does not tell us whether the
"isTranslated"-values of rule and graph object do coincide or not.
Hence, we need the patch and would be very happy if you could
integrate it.
The patch is very general and allows Henshin users to add
user-specific constraints to the matching process.
(If no user constraints are needed, nothing has to be done and
everything works as before.)
Here is a short description of the changes in this patch (based on
revision 1243):
1) in org.eclipse.emf.henshin.matching
- new class in Package constraints: public abstract class
UserConstraint implements Constraint
2) in org.eclipse.emf.henshin.interpreter
- new class: public abstract class HenshinUserConstraint extends
UserConstraint
- in class EmfEngine:
+ a new variable
private HashMap<Class<? extends UserConstraint>,
Object[]> userConstraints = new HashMap<Class<? extends
UserConstraint>,Object[]>();
+ a new method
public void registerUserConstraint(Class<? extends
UserConstraint> con,Object... params)
Using the patch in our particular case:
Method registerUserConstraint is called in execute() by us in
tggeditor.commands.ExecuteRulesCommand:
HashMap<Node, Boolean> isTranslatedNodeMap = new
HashMap<Node, Boolean>();
emfEngine.registerUserConstraint(RuleConstraint.class,
isTranslatedNodeMap);
The RuleConstraint class is our TGGEditor class
tggeditor.commands.RuleConstraint and extends
HenshinUserConstraint and implements the source consistency check
we need.
I attach the patches for matching and interpreter. Please have a
look and tell us what you think.
Best,
Claudia
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|
