Ed,
After a quick reading. I prefer to wait to the o.e.o.examples.xtext
contributions to follow the email.
Cheers,
Adolfo.
El 04/04/2010 12:59, Ed Willink escribió:
Hi
I expect to commit
org.eclipse.ocl.examples.xtext.{essentialocl,completeocl,oclinecore}{..ui}
shortly.
The essentialocl editor provides a single _expression_ editor,
potentially useable by the OCL Interpreter or as a popup in UML tools.
Interface may need adjusting once actually used by someone. The other
editors extend the essentialocl editor.
The completeocl editor supports *.ocl documents. It does not (yet)
build to produce a corresponding *.oclecore that noone uses anyway.
There is therefore no need to transform the XtextCST to the existing
CST. Users edit a *.ocl text document with assistance from the LL
grammar. In due course a build will use the existing text to CST to AST
LALR parser unchanged.
The oclinecore editor currently supports *.oclinecore documents that is
an EssentialOCL in EMFatic concrete syntax. My next job is to serialise
on load and save the Ecore, so that the oclinecore editor is just
another editor for *.ecore. No *.oclinecore file at all.
I've temporarily lost much of the semantics from the LL grammar so X::Y
is just two concatenated text strings. Whether this can be fully
resolved semantically in the LL grammar is work in progress. Maybe we
need to project the errors from the existing parser and analyser to
provide the semantic messages within Xtext.
Anyway the completeocl and essentialocl editors now provide a useful
text document/line develoipment assistant. The oclinecore should be an
advanced Ecore assistant shortly. This gives the editors a modest but
definitely useful functionality. How much of the further work to
prettify outlines, code templates quick fixes gets done is just a
matter of time. The more the better.
Xtext is very keen on an import statement with a little built of
built-in semantic support. I'm therefore inclined to add an import
construct to CompleteOCL (which was never complete in the OCL
specification anyway). An import is much more obvious to the user than
poking around in the Model Registry.
Regards
Ed Willink
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|