Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Xtext OCL editor progress

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


--

Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

Back to the top