| Re: [jwt-dev] JWT meta model changes |
Hi Florian, you're right. I've updated the table to show that XOR/AND node classes should be created as concrete types. In my opinion, we could handle this (relatively) easily in our default views by a single AND and XOR editpart respectively which checks the type of the associated model object and acts accordingly. This way we would have a consistent standard behavior while additional views can still provide their own figures. Concerning the UI, I would suggest providing only either XOR/AND or Decision/Merge/Split/Join in the standard palette and putting the other one in another palette folder (e.g. "additional elements" which we could also use in the future to put rarely used classes) because otherwise it would be way too confusing for users. Additionally, a context menu entry could be added for the nodes which allows to replace it by a specialized/generalized type. Regards, Chris Am 04.05.2010 19:42, schrieb Florian Lautenbacher:
Hi Chris, thanks for the update. Just some minor comments: - 3) XORNode: Create as abstract class (similar to ANDNode); The only thing that only now comes to my mind is: if it is an abstract class what use does it have for us? The idea at the beginning was to have a class with its own view (especially: editpolicy and figure) which can have several incoming *and* outgoing edges in difference to DecisionNode and MergeNode. However, if it is an abstract class, it won't be usable in such a way, so we maybe should discuss this further and either decide to neglect this requirement and don't integrate these classes at all or make them concrete classes. On the other side, if it is a concrete class then the views must specify whether to show only the more general class or only the two more specific ones and we need some logic when switching the view: a) from specific to general: simply use the figure of the more general class and keep the specific class in the background b) from general to specific: if a specific class is hold in the background: no problem, otherwise evaluate the node whether it has only one incoming or only one outgoing edge and make it a DecisionNode (MergeNode respectively); If no such case (changing view from more general class to more specific and the node has several incoming and outgoing edges), then an error message comes up. - 9) Remove also package PrimitiveTypes Best regards, Florian -----Ursprüngliche Nachricht----- Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Christian Saad Gesendet: Montag, 3. Mai 2010 10:56 An: Java Workflow Tooling Betreff: Re: [jwt-dev] JWT meta model changes Hi Marc, thanks for the update. Seems we won't be changing too much (makes life easier) :) * InformationType is still required by Mastek * Input/OutputParameter by OpenWide I've updated the table accordingly. Regards, Chris Am 30.04.2010 20:04, schrieb Marc Dutoo:Hi Chris, Florian, all I know that we know have our "magical" converter to handle metamodel evolution :) But still, don't remove features that can be useful. Please add a column that says for each evolution how the converter transformation will handle it if not obvious, or whether it won't be supported. So I agree with Florian, and further : 1. remove information type OK 2. merge input and output parameters NO we are using it today to deduce the signature of service calls ! Or another idea about that ? I agree we could add (web)service specific attributes or aspects to define the signature, but it would be a duplicate of the parameters attribute anyway. Further, being able to deduce the service signature from the standard model is a pretty powerful feature I think. 3. remove functions OK 4. and 5. as Florian says (add new ones, but keep the old ones) 6. move to executable node OK 7. and 9. java application OK 8. remove application type OK 10. webservice application OK cosmetics, supported evolution 11. remove primitive types OK Regards, Marc Christian Saad a écrit :Hi Florian, thanks for your input, I've updated the list accordingly. It seems I misunderstood the requirements for AND/XORNode, so I added them as additional abstract nodes. I also added the primitive types for removal since I couldn't find any concrete reference to them in the meta model anyway and sent a message to Ravi as Mastek asking about the informationType. Unfortunately the GSoC currently doesn't look so good but maybe we can provide another funding here (like PvS-SoC ;) ). Regards, Chris Am 23.04.2010 18:24, schrieb Florian Lautenbacher:Hi Chris, thanks for the detailed list. I have some objections of unifying the DecisionNode/MergeNode and ForkNode/JoinNode while removing those nodes at the same time (I'm not sure whether this was the intended meaning of unification); as those nodes are typical for UML and are heavily used in all of our models as well as have different EditPartPolicies I would like to see those elements stay but rather get more abstract nodes *additionally*. What do others think about it? Concerning the attribute informationType I'm unsure whether our Indian colleagues are using it and if yes, for which purpose. I think I've once seen a model which made use of them. I'm not sure who currently uses the primitive types, so I would agree to remove those, too. Concerning the swimlanes: is there already a decision whether the GSoC student can assist us here? Best regards, Florian -----Ursprüngliche Nachricht----- Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Christian Saad Gesendet: Freitag, 23. April 2010 17:29 An: Java Workflow Toolbox Betreff: [jwt-dev] JWT meta model changes Hi guys, the long overdue list of proposed metamodel changes. This is supposed to become the detailled list of changes which will then be applied to the meta model once everybody gives their +1 Regards, Chris _______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev------------------------------------------------------------------------ _______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev_______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev_______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev
Attachment:
JWTMMChanges_v3.xls
Description: MS-Excel spreadsheet