Community
Participate
Working Groups
Provide a query delegate text viewer implementation (and factory) which adapts the source viewer of the OCL interpreter (interactive console) example for use within the EMF Ecore data set editor.
Created attachment 185585 [details] ocl query delegate text viewer Here are changes to the OCL console example which adapt its source editor as a query delegate text viewer; see corresponding patch attached to bug 332961 for details.
This patch is nice and simple and only affects examples so no fundamental problem. We have the practical problem again of waiting for an EMF I-build. Where can I tell that it's working? does the OCL console suddenly provide a proxy editor for an EAnnotation in the Sample Ecore Editor or ...? The overridden createHelper is not very elegant; the override is for an initialization, rather than helper creation so perhaps an initEnvironment() would be more focussed. But I can't see any reason why the derived code should not be present directly by adding an OCLDocument.setParameters. Existing users will see an empty parameter list, new usage has the opportunity for 'global' variables as well as context. Adding setParameters might go hand in hand with solving the missing 'Load Resource...' functionality. [Patch also needs some @since 3.1's]
(In reply to comment #2) > This patch is nice and simple and only affects examples so no fundamental > problem. We have the practical problem again of waiting for an EMF I-build. I'll create an integration build of EMF as soon as Ed (Merks) has reviewed the changes there, hopefully sometime today. > Where can I tell that it's working? does the OCL console suddenly provide a > proxy editor for an EAnnotation in the Sample Ecore Editor or ...? Right now it surfaces in the EMF ODA data set editor, accessible from BIRT. I'll be posting instructions on how to try it out at some point in the near future... > The overridden createHelper is not very elegant; the override is for an > initialization, rather than helper creation so perhaps an initEnvironment() > would be more focussed. But I can't see any reason why the derived code should > not be present directly by adding an OCLDocument.setParameters. Existing users > will see an empty parameter list, new usage has the opportunity for 'global' > variables as well as context. OK, I'll add setParameters to the document class and attach a new patch. > [Patch also needs some @since 3.1's] I'll add those and the missing references to this bug number as well.
Created attachment 185646 [details] updated patch Here's an updated version of the patch which (I hope) addresses your concerns. I'll let you know once the EMF changes have been committed and an integration build is available.
Looks good. +1. It would be nice to see it in action before committing it.
(In reply to comment #5) > Looks good. +1. Thanks!!! > It would be nice to see it in action before committing it. Would screen shots suffice? Or would you like to do a Skype demo? I'll try to find time to write up the steps for trying it out, but I'd like to have an integration build with the changes by the end of this week if possible, so I'm not sure whether time will permit...
The changes to org.eclipse.emf.edit.ui have been committed. I'll initiate an integration build now...
Kenn, I would also like to see the resulting UI of these changes. P.S: As soon as the code is in the CVS your requested Integration build could be made quickly. We got a failure in our last nightly build, but it seems that it was due to build servers issues. Cheers, Adolfo.
Created attachment 185660 [details] screen shot Here's a screen shot showing the integrated OCL text viewer in action.
Thanks. That makes more sense now. As and when the Xtext editor takes over it should be arther similar but with configurable coloring and more features. Adolfo: Are you happy for a commit?
An integration build containing the EMF changes is now available.
(In reply to comment #10) > Thanks. That makes more sense now. > > As and when the Xtext editor takes over it should be arther similar but with > configurable coloring and more features. > > Adolfo: Are you happy for a commit? I'm not unhappy with it ;=). When I reviewed the code at work I didn't found any strange thing. Go ahead with the commit, and I'll prepare the build tomorrow. Regards, Adolfo.
Ed, I've committed the changes to the CVS so that we may prepare the I-build. Cheers, Adolfo
Ooops, I forgot to resolve. Commited to CVS HEAD. It will be avaiable in the next M5 (and I-builds ;) ) P.S: Kenn, our p2 repo URL corresponding to the last successful integration build: http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0
(In reply to comment #14) > Ooops, I forgot to resolve. > > Commited to CVS HEAD. It will be avaiable in the next M5 (and I-builds ;) ) Thanks! > P.S: Kenn, our p2 repo URL corresponding to the last successful integration > build: http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0 Uh, is that where you place integration builds? Or did you mean http://download.eclipse.org/modeling/mdt/ocl/updates/integration/3.1.0?
Sorry Kenn, The following is the correct one. Let me know if it works well: http://download.eclipse.org/modeling/mdt/ocl/updates/interim/3.1.0 Regards, Adolfo.
Closing
