Eclipse Community Forums: TMF (Xtext) » Non editable elements

Home » Modeling » TMF (Xtext) » Non editable elements

Non editable elements [message #1855527]

Wed, 19 October 2022 11:11

Eclipse User

Hi,

I have two different scenarios I am working on but they both require the same thing. To restrict the user from editing a particular piece of text.

Scenario 1: I have a grammar with classes A and B. I want the user to be able to edit class A and its attributes and references but not class B (should be read-only for the user and will be populated by some model transformations).

Scenario 2: I have a grammar with classes A and B and another Ecore metamodel with classes C and D. I want to be able to show some information from class C located in the Ecore meta model, in the textual grammar (which does not contain class C).

Are there any Xtext features that support what I want to do in Scenario 1 and 2?

Thank you!

Re: Non editable elements [message #1855531 is a reply to message #1855527]

Wed, 19 October 2022 13:48

Eclipse User

I don't know if anybody has implemented this ever.
I also don't know if you talk about file or about editor
Maybe code minings is the feature you are looking for

Re: Non editable elements [message #1855544 is a reply to message #1855531]

Thu, 20 October 2022 03:14

Eclipse User

Hi

I think there might be a very simple solution.

Presumably you have a list of start+end char indexes for the read-only regions, so you can just override AbstractDocument replace() in your custom XtextDocument. If the replacement overlaps a read-only section just ignore/offer a popup apology. If you're cleverer you can honor the outside read-only range replacements to support a mega-paste.

You can probably arrange some background/foreground color/font to make the read-only ranges visible.

Specify a custom XtextDocument in e.g org.eclipse.ocl.xtext.oclinecore.ui.OCLinEcoreUiModule by

@Override
public Class<? extends XtextDocument> bindXtextDocument() {
return OCLinEcoreDocument.class;
}

If you want to start 'improving' Xtext you might emulate org.eclipse.ocl.xtext.base.service.RetokenizingTokenSource that sits between lexer and parser to retokenize the regularly parsed tokens of your read-only code as a new aggregate READONLYREGION grammar element. Subsequent Xtext activities such as content assist/quick fix/rendering/formatting could then be more sensitive to the context.

Regards

Ed Willink

Re: Non editable elements [message #1855548 is a reply to message #1855531]

Thu, 20 October 2022 04:39

Eclipse User

Would it make a difference if we are talking about the file or the editor?

Let us say that for a particular grammar (meta model) I know in advance the elements that should not be allowed to be edited (certain EClasses, EAttributes, or EReferences). What can happen next is that I generate textual models conforming to this grammar via model transformations. The output should be a textual model where the elements I was talking about earlier should not be allowed to be edited.

I already checked code mining and it says:

Quote:

Shows inline annotations in the text editor that are not part of the text itself, but derived from its contents.

Correct me if I am wrong, but saying not part of the text itself, I would guess it also means not part of the grammar at all.

Re: Non editable elements [message #1855552 is a reply to message #1855548]

Thu, 20 October 2022 05:19

Eclipse User

yes, not in the file, not in the grammar

Previous Topic:	whether Xtext/Xtend have some ways to develop DSL debugger
Next Topic:	Resource not present in the ResourcesSet

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 13 23:33:29 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter