Help with replacing XWT

[EnricoBragante]

Hello,

our project (Eclipse based IDE) uses XWT xml UI files not only for displaying custom UIs, but also for code generation purposes.
Basically, the UI xml files are parsed by a custom component in order to extract names, properties and types of UI elements. This information is then used for enriching other functions of the IDE.

With XWT gone, the UI xml files are also gone. Replacing the UIs is not difficult: we just need to refactor our editors and custom components in order to use the standard java swt windowbuilder API.

The issue is with our own code generation feature: we need a way to get information about the structure and components in a UI.
Parsing the XML files was fairly easy. But now we only have Java files.
I see two ways, and I am kindly asking for your opinion:

1. Create an AST of the generated UI java files and extract the information from there
   I don't like this solution a lot, because:

• I have to distribute the java source files.
• Java source files are not meant to be used for this
• AST processing logic is involved, which isn't easy to understand and maintain by all developers

2. Generate an additional UI structure "description" file together with the UI java files
   I like this solution because:

• It gives me the freedom of choosing the format (and the serializing/deserializing framework)
• I can store only the information I need about our UIs

Do I see it correct? Are there other options in your opinion?
Also, for solution two, what implementation pattern using the Windowbuilder API do you suggest?

Thank you very much for the support
Enrico Bragante

[merks]

@ptziegler

FYI, the XWT contribution to SimRel got re-enabled...

[EnricoBragante]

Thank you @ptziegler for the info. Does this mean windowbuilder is going to re-integrate xwt support?
Our main issue at this point is that "org.eclipse.wb.internal.core.xml" was completely removed

[ptziegler]

XWT might've been re-enabled but as far as I can tell, it's -for all intents and purposes- unmaintained. The last change, was done 4 months ago and even that was just to get everything running again with the Eclipse IDE.

But even there I already see them approaching the next disaster: They are still using the javax packages, so within the near future, it will -yet again- no longer work.

At the end of the day, dropping support for XWT was already planned some time ago. Especially with the limited amount of time that I can invest into the project. I only held it back because it kept working. And once it no longer did, it got removed.

Given that I want to avoid the eternal limbo of removing XWT whenever it breaks and to bring it back once they fix, I don't think it makes sense to consider a re-integration - at least not given its current state.

That said: XWT is not gone, it's just not longer supported by WindowBuilder. I didn't quite get whether you use XWT on its own or whether you use WindowBuilder. Is WindowBuilder integrated in your editors or do you have your own approach of visualization?
If it's just about using parsing the XML file, then I wonder whether it's easier to simply use JAXB or something similar.

[EnricoBragante]

Thanks for the explanation. Very clear.

I am sorry I was not able to explain my use case better. We do use windowbuilder to generate UIs in XWT format.
Later on we use the XWT xml also for other purposes other than rendering the UI with XWT.
Now we want to remove XWT, and the java files generated by Windowbuilder are the only thing we have.
I need a way to get some information about the generated UI later on. Information about list of components used, their properties, etc.
I would like windowbuilder to generate additional files in addition to the java files, with a format of my choice. Is it possible?

[ptziegler]

I don't think it makes sense to have this functionality directly within WindowBuilder. However, you can use the org.eclipse.wb.core.java.rootProcessors extension point to inject your own logic. You need to contribute your own implementation of IRootProcessor which, form what I remember, should be called whenever the Java code has been parsed by WindowBuilder.

If you then apply the ObjectInfoVisitor on the root node, you should go through all UI elements that make up the Java class. This information you can collect and store in whatever format you want.

Would this fit into your workflow?

[EnricoBragante]

Yes this would fit perfectly. Thank you.

When you say you don't think this feature should be part of WindowBuilder, you mean the WindowBuilder project should not provide this feature, or do you mean I should not implement this feature by using WindowBuilder?

[ptziegler]

When you say you don't think this feature should be part of WindowBuilder, you mean the WindowBuilder project should not provide this feature, or do you mean I should not implement this feature by using WindowBuilder?

If you need to store additional information about the composite, then that should be done by your application and not by WindowBuilder. We only give you the ability to do so by means of the extension point.

[EnricoBragante]

I also agree. This is a specific use case which has less to do with the scope of WindowBuilder.
Thank you for the valuable information you provided to me.