| Linking to the fxgraph model from another xtext language [message #1201161] |
Thu, 21 November 2013 16:04  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm working on an Xtext-based DSL for implementing (what is essentially)
the controller-part of an application, and want to support javafx
applications. I can use efxclipse to create the layout and render the
javafx ui by loading the generated fxml, and link into the graph of
javafx nodes using their ids (#id CSS lookup). However, the ids are
string constants in my DSL and I would like to make them proper Xtext
cross references to elements in the fxgraph file, so I can provide some
level of validation and completion.
The question is, what kind of EObjectDescriptions are available for use
with scoping from my own DSL? Ideally, I have access to the id AND java
type (JvmTypeReference identifier) of the element, so I can provide type
validation without actually resolving the reference and loading the
fxgraph file.
Any suggestions for how to approach this?
Hallvard
|
|
|
| Re: Linking to the fxgraph model from another xtext language [message #1201234 is a reply to message #1201161] |
Thu, 21 November 2013 16:42  |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
I'm not sure I can completely follow ;-) Is your question whether we
have in internal cache that holds file&id => type mapping?
The the answer is unfortunately no, we don't. I think the reason is that:
e(fx)clipse dev process:
------------------------
FXML/FXGraph: active (FXML/FXGraph know their controller)
Java-Controller: passive
your dev process:
-----------------
FXML/FXGraph: passive
YOURDSL: active (controller knows UI)
Anyways, if there's something e(fx)clipse can do to make your life
easier I'm all for it and add whatever you want (eventually when we want
to implement proper refactor/rename we'll probably need those
informations ourselves!)
Tom
On 21.11.13 17:04, Hallvard Trætteberg wrote:
> Hi,
>
> I'm working on an Xtext-based DSL for implementing (what is essentially)
> the controller-part of an application, and want to support javafx
> applications. I can use efxclipse to create the layout and render the
> javafx ui by loading the generated fxml, and link into the graph of
> javafx nodes using their ids (#id CSS lookup). However, the ids are
> string constants in my DSL and I would like to make them proper Xtext
> cross references to elements in the fxgraph file, so I can provide some
> level of validation and completion.
>
> The question is, what kind of EObjectDescriptions are available for use
> with scoping from my own DSL? Ideally, I have access to the id AND java
> type (JvmTypeReference identifier) of the element, so I can provide type
> validation without actually resolving the reference and loading the
> fxgraph file.
>
> Any suggestions for how to approach this?
>
> Hallvard
|
|
|
| Re: Linking to the fxgraph model from another xtext language [message #1201323 is a reply to message #1201234] |
Thu, 21 November 2013 17:39 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 21.11.13 17:42, Tom Schindl wrote:
>
> I'm not sure I can completely follow ;-) Is your question whether we
> have in internal cache that holds file&id => type mapping?
I'll try to explain again...
My DSL includes rules that describe what should happen when this and
that event occurs on widgets. These widgets are typically created by
loading files like fxml and swixml files and subsequently linked to by
an id at runtime. It would be great to be able to complete and validate
these id at design time.
In the case of fxgraph, which AFAIU is based on Xtext, it should be
possible to do this using ordinary Xtext cross-references, the ones used
when you write feature=[MetaType|QualifiedName] in your grammar. These
QualifiedNames are linked through a global scope to objects that are
exported from other resource. Xtext handles this by managing an index
with mappings from of ids to EObject uris, that is updated when
resources are pre linked. By default all EObjects in a resource are
exported with their QualifiedNames as ids. However, a DSL implementor
can customize the information that will be provided through the index in
several ways: 1) defining which objects are exported (visible), defining
what their ids are and 2) defining what information besides the id and
uri that is stored in the index.
The question is what EObjects are exported (explicitly or by default)
with what ids today, and if it's possible in the future to export all
objects with an id (fxml:id or ^id property) and include their JvmType
identifier so other DSLs provide some level of type checking.
I hope this was clearer.
Hallvard
> Anyways, if there's something e(fx)clipse can do to make your life
> easier I'm all for it and add whatever you want (eventually when we want
> to implement proper refactor/rename we'll probably need those
> informations ourselves!)
>
> Tom
>
> On 21.11.13 17:04, Hallvard Trætteberg wrote:
>> Hi,
>>
>> I'm working on an Xtext-based DSL for implementing (what is essentially)
>> the controller-part of an application, and want to support javafx
>> applications. I can use efxclipse to create the layout and render the
>> javafx ui by loading the generated fxml, and link into the graph of
>> javafx nodes using their ids (#id CSS lookup). However, the ids are
>> string constants in my DSL and I would like to make them proper Xtext
>> cross references to elements in the fxgraph file, so I can provide some
>> level of validation and completion.
>>
>> The question is, what kind of EObjectDescriptions are available for use
>> with scoping from my own DSL? Ideally, I have access to the id AND java
>> type (JvmTypeReference identifier) of the element, so I can provide type
>> validation without actually resolving the reference and loading the
>> fxgraph file.
>>
>> Any suggestions for how to approach this?
>>
>> Hallvard
>
|
|
|
Powered by
FUDForum. Page generated in 0.03533 seconds
] 
Search
Help
Register
Login
Home
