Free text editor inside Concrete
42 views
Skip to first unread message
Marcin Stefaniuk
Oct 14, 2011, 5:40:55 PM10/14/11
to Concrete Model Editor
Finally I worked out an example of DSL free text editor with code
completion. You can find it on GitHub project on
https://github.com/mstefaniuk/Concrete-Freetext (there is also link to
demo page).
Main purpose of my work was to build free text editor of DSL. Concrete
itself is perfect for structured editing (metamodel, statemachine) but
for an expression language it is not so convenient. It is not easy for
example to edit conditions for state transitions. I think that in
particular cases there is a need to combine structuralized and free
text editing capabilities.
Currently my project uses PEG grammar as language definition. But I
can imagine situation when in Concrete metamodel there will be a flag
for entity (and all its substructures) to be edited in free text
manner instead of structuralized. The parser can be generated from
metamodel (via PEG.js) on the fly.
What do you think about this approach?
completion. You can find it on GitHub project on
https://github.com/mstefaniuk/Concrete-Freetext (there is also link to
demo page).
Main purpose of my work was to build free text editor of DSL. Concrete
itself is perfect for structured editing (metamodel, statemachine) but
for an expression language it is not so convenient. It is not easy for
example to edit conditions for state transitions. I think that in
particular cases there is a need to combine structuralized and free
text editing capabilities.
Currently my project uses PEG grammar as language definition. But I
can imagine situation when in Concrete metamodel there will be a flag
for entity (and all its substructures) to be edited in free text
manner instead of structuralized. The parser can be generated from
metamodel (via PEG.js) on the fly.
What do you think about this approach?
Meinte Boersma
Oct 17, 2011, 5:56:00 AM10/17/11
to Concrete Model Editor
Hi Marcin,
Good stuff!
Do you also have an example where you embed your approach into a DSL
editor made with Concrete to make editing of expression language
fragments easy. Your current demo example is essentially standalone
and outputs a meta model in Concrete's meta model format, but I think
the situation where you produce pieces of a model in Concrete's model
format is more interesting since I think it's more interesting to use
Concrete for editing models rather than just for editing meta models.
After all, you'd typically need far fewer meta models than actual
models.
Good stuff!
Do you also have an example where you embed your approach into a DSL
editor made with Concrete to make editing of expression language
fragments easy. Your current demo example is essentially standalone
and outputs a meta model in Concrete's meta model format, but I think
the situation where you produce pieces of a model in Concrete's model
format is more interesting since I think it's more interesting to use
Concrete for editing models rather than just for editing meta models.
After all, you'd typically need far fewer meta models than actual
models.
Marcin Stefaniuk
Oct 18, 2011, 1:27:37 AM10/18/11
to Concrete Model Editor
Frankly speaking my example is a bad example. It allows to edit
Concrete metamodel which is also convenient to edit in structural way.
Recently I've used similar content assisted textarea for XPath in
Schematron editor - but I've not used Concrete but XForms.
Integration with Concrete should not be hard. It can be also done in
two ways. Simpler can be based on external grammar (similar to mine
example) and plugged into particular attribute. Harder one would build
editor from part of Concrete metamodel hierarchy. The former gives
finegrained control of expression language but returning of JSON
structures need to be programmed, the latter would build JSON
automatically.
Maybe in next two weeks I would prepare an example of one of above
approaches.
Concrete metamodel which is also convenient to edit in structural way.
Recently I've used similar content assisted textarea for XPath in
Schematron editor - but I've not used Concrete but XForms.
Integration with Concrete should not be hard. It can be also done in
two ways. Simpler can be based on external grammar (similar to mine
example) and plugged into particular attribute. Harder one would build
editor from part of Concrete metamodel hierarchy. The former gives
finegrained control of expression language but returning of JSON
structures need to be programmed, the latter would build JSON
automatically.
Maybe in next two weeks I would prepare an example of one of above
approaches.
mthiede
Oct 18, 2011, 4:19:38 AM10/18/11
to Concrete Model Editor
Hello Marcin,
you show an interesting approach to solve the current "expression
problem" with Concrete.
Actually I think it is not fully possible to derive the parser from
the metamodel only. I guess you will always need something like
precedence for operators for example.
So maybe we should try to come up with a definition of which
attributes need to be annotated to the metamodel in order to
facilitate this.
My idea here would be to keep it as simple as possible. I.e. to allow
for expression languages which can be used efficiently but not allow
for any fancy syntax or grammer. This could also simplify migration to
a non parser based approach (see below). Keep in mind that the text
which is subject to parsing is only a means to create a model element
tree (at least in my understanding). So after typing it and parsing
it, it would no longer be visible, it would be replaced by the model
element tree. This means that fancy syntax in the parser step is not
important, you can style the look of the expression using the HTML
templates and CSS. On the other hand, simple syntax could mean that
all Concrete expression languages work in a similar way and if users
got used to the concept for one language, it would be easy for them to
work with another language.
Maybe such a parser based solution is just an intermediate step. I
really want to evaluate an approach similar to the one used by MPS.
(I.e. trigger tree rewriting on certain keystrokes). Ideally, the same
description language (i.e. metamodel with attributes) could be used.
I'm looking forward to see your example!
you show an interesting approach to solve the current "expression
problem" with Concrete.
Actually I think it is not fully possible to derive the parser from
the metamodel only. I guess you will always need something like
precedence for operators for example.
So maybe we should try to come up with a definition of which
attributes need to be annotated to the metamodel in order to
facilitate this.
My idea here would be to keep it as simple as possible. I.e. to allow
for expression languages which can be used efficiently but not allow
for any fancy syntax or grammer. This could also simplify migration to
a non parser based approach (see below). Keep in mind that the text
which is subject to parsing is only a means to create a model element
tree (at least in my understanding). So after typing it and parsing
it, it would no longer be visible, it would be replaced by the model
element tree. This means that fancy syntax in the parser step is not
important, you can style the look of the expression using the HTML
templates and CSS. On the other hand, simple syntax could mean that
all Concrete expression languages work in a similar way and if users
got used to the concept for one language, it would be easy for them to
work with another language.
Maybe such a parser based solution is just an intermediate step. I
really want to evaluate an approach similar to the one used by MPS.
(I.e. trigger tree rewriting on certain keystrokes). Ideally, the same
description language (i.e. metamodel with attributes) could be used.
I'm looking forward to see your example!
Marcin Stefaniuk
Oct 19, 2011, 4:33:40 PM10/19/11
to concret...@googlegroups.com
I have realised that maybe there are two loosely coupled languages.
One structural kind (eg. statemachine) and second expression kind (eg.
transition condition). Both exist in the same domain and shares some
concepts like "process variable".
I have also serious doubts if expression should be stored in JSON
entity structure. Usually it is too much verbose in contrast to user's
perception. Additionally expression is expected to be easily
evaluated. It can be done during parsing - easier than AST
interpretation.
One structural kind (eg. statemachine) and second expression kind (eg.
transition condition). Both exist in the same domain and shares some
concepts like "process variable".
I have also serious doubts if expression should be stored in JSON
entity structure. Usually it is too much verbose in contrast to user's
perception. Additionally expression is expected to be easily
evaluated. It can be done during parsing - easier than AST
interpretation.
When we concentrate on expressions (conditions, assignments etc)
without statements it should be easy to build grammar from extended
metamodel. When we introduce new metamodel class "Expression" with
options unary, binary and ternary and allow to define primary elements
it should be enough - also for operators precedence.
2011/10/18, mthiede <martin...@gmx.de>:
--
Wysłane z mojego urządzenia przenośnego
Marcin Stefaniuk
mar...@stefaniuk.info
http://eutechne.stefaniuk.info
Meinte Boersma
Oct 21, 2011, 8:36:35 AM10/21/11
to Concrete Model Editor
Hi Marcin,
What you're proposing is essentially called Xtext ;)
I don't think an approach which really expands the current meta meta
model underlying Concrete is the way to go, since it would "just" be
an abstraction of expression grammars and, as Martin pointed out, he'd
rather solve the expression problem through triggered tree rewrites.
For each particular language, it's probably easiest to configure a
specific parser "widget" which simply returns JSON tree fragments. You
could expand your current example with the expression grammar
abstraction (encapsulated in an "Expression" meta model class) which
maps down to a Concrete meta model. The mapping would be very useful!
What you're proposing is essentially called Xtext ;)
I don't think an approach which really expands the current meta meta
model underlying Concrete is the way to go, since it would "just" be
an abstraction of expression grammars and, as Martin pointed out, he'd
rather solve the expression problem through triggered tree rewrites.
For each particular language, it's probably easiest to configure a
specific parser "widget" which simply returns JSON tree fragments. You
could expand your current example with the expression grammar
abstraction (encapsulated in an "Expression" meta model class) which
maps down to a Concrete meta model. The mapping would be very useful!
Reply all
Reply to author
Forward
0 new messages