Created a quick prototype for serializing Vaadin component trees to XML and back. The prototype supports all UI components (including your own), most properties in them and about the 70% of the layouts. I tried to keep the XML notation as simple to write (by hand) and as close to Vaadin API spec as possible.
Maybe it would be a good idea to use some “standard” XML UI language, or maybe they’re just too complicated
One possible would be XUL (https://developer.mozilla.org/en/XUL_tutorial).
A quick look in buttons, tabsheet and layouts shows that they contain about the same elements.
Seriously, do you have some real use for this? I have got a strong feeling that the Vaadin user base is growing because developers don’t need to use XML ( or javascript ), but plain Java.
If you want to work on that level on holidays and want to do something useful, I’d have a suggestion for you. Build a bit similar tool that takes UIDL messages as input (the JSON data we use to send updates to client) and builds java code that creates similar UI. That combined to “record UI state” button in debug console, would really save my time next year when resolving client side rendering issues. And there would be no need for no extra code to core Vaadin.
Declerative XML for GUI are great, because you keep gui layout out of business logic. It is also much easier to separate those two tasks.
Also, Gtk does it with glade, QT has creator that creates .ui files that can then be read into all kinds of languages (I tried it with ruby, python, but it would also work with java and c++).
Programmer doesn’t have to know or even see inside XML files, he just uses editor. When user mask changes, the java file with business logic doesn’t have to.
So, by all means, do it!
The greates it would be, if you could just reuse QT .ui files and their fantastics creator.
Also, I find this utility method to be very useful with declerative guis:
class Test extends Window{
public Test(){
XMLUI ui = new XMLUI();
ui.readFrom(myInputStream);
addComponent(ui.getRoot());
ui.injectVariables(this); //code that matches variables from ui and java class and injects values into variables.
// in this case, same as myButton = (Button) ui.getById("myButton");
myButton.addListener( this)
}
public Button myButton; //waiting for injection
So ui.injectVariables does this: for each component in ui it tries to find field in java file, if it exists and has the same name, it sets fields value to currenty created.
Also, I sometimes do the same for event handling methods, like it searches for on_myButton_pressed methods and connect button on click event to that method.
I considered using XUL, but for three reasons decided against it: 1) XUL does not have 1:1 mapping to Vaadin UI components. Thus by using XUL it should either be extended (a lot) or only subset of Vaadin features used, 2) Extended XUL would need lots of documentation; the current XML dialect is (almost) a 1:1 mapping to Vaadin Java API, 3) Implementing direct mapping of Java API keeps implementation simple as we can use inspectors and reflect.
That said - it should be possible to write a XUL to Vaadin XSLT.
I am not a fan of XML UI dialects myself either. Definitely they are not the way to build all of your UI:s, but might be suitable for solving some development, testing or prototyping problems.
If you want to try to build this, be my guess. XMLUI is as simple as described above - you could just take getRoot() and traverse through your data model and set the values. If you like.
Right, I think that the UI editor is what developers mostly want - not exactly any (new?) XML syntax to write. Moreover, it does not matter how you persist the UI you create using editor. I don’t think you ever want to actually write it by hand.
Fully agree. I hope the WYSIWYG editor will be ready asap.
XMLUI is not a replacement or even competitor to WYSIWYG editor. Just a simple tool for serializing UI component trees to XML and deserializing from XML. If I finish this, it will be published in the directory.
XMLUI is designed to produce/read human readable/writable XML. So yes, the purpose is to make it possible to write it by hand. Still, most developers probably would not want to use this. But I hope some might find it useful.
Personally, I’m not too keen. I mean, I can see the point if you have an visual editor, but coding that sort of thing directly in XML makes me come out in hives.
In our main project, part of our Swing gui is declared in XML (Data binding) : it was a design choice I made about five years ago, and it was a bad one; it’s verbose, hard to read, and hence a complete pain to maintain - and that was only for a tiny portion of the GUI.
So, if you plan on making the Eclipse WYSIWYG editor read/write XML, then yes I can see it’s worth pursuing - but if not then, um, not.
Just my two-penny-worth.
Cheers,
Charles
(I don’t suppose there are any plans to make the Eciple WYSIWYG editor standlone, are there? No. No, I thought not.)
No plans, BUT the editor part already (almost) works independently of Eclipse. This enables integration to other IDEs as well as embedding the editor to ones own applications (and running it on web).
Actually I thought that the next step would be to add the wysiwyg to my prototype - making it possible to edit XML visually.
I would like it for debugging. I would add it to the debugger window: please dump the UI state. This would make certain kinds of non-regression tests easy – lay out the structure programmatically, check visually, dump the UI structure. Re-run later, check that structure is same.
It seems that this XMLUI thing has divided the opinions - badly. In any case - when I have some time to clean the implementation, i’ll push it to contrib and to Vaadin Directory.
Meanwhile, here is an idea to push the thing even further:
?xmlui to show the structure of the application UI state
How about adding possiblity of seeing the current windows current view state as XML to all Vaadin applications? By default?
Functionality:
Whenever a user adds ?xmlui to URL (just like ?debug), an XML document would be outputted to browser as described in the above forum thread
Add functionality to enable/disable this feature in web.xml
Why on earth? Making it easier for people to see how an UI has been created, makes it a lot easier for them to learn to make better Vaadin UI:s themselves. Some may argue that the “view source” -button was one of the major reasons why HTML got so popular. One might also consider possibility of using snippers of that XML to initialize UI trees…
This sounds like a great feature but why XML if it is about people seeing how an UI has been created? XML is not meant to be human readable but computer readable. I see the point of being able to export (“borrow”) the layout from one application to import it in your own but that sounds like a different use case. If it is made for humans, why not produce a visual component tree? Or java code right away? Web pages are created in HTML and the source can be viewed in HTML. Vaadin programs are per default not created using XML.
Visual component tree could be even better. Java-code might give wrong impression that the code is the same one written by the developer and thus give impression of a potential security vulnerability. XML is useful only if the XMLUI tool could be for initializing the UI also in practice.
I think that the largest problem is: how to motivate the developer to show the UI structure. One motivation would be laziness - to have the feature on by default. Unfortunately some may find having this on by default somewhat impolite. Maybe the best compromise is to have “enableUIStructureView = true” parameter that defaults to false in sample web.xml and eclipse wizard generated web.xml.
