Idea is good and implementation seems elegant. In fact the idea is so good, I really would like to see it developed and the limitations and bugs eliminated. It is frustrating that patches sent to the author have not been applied.
The idea is that an XUL DOM is created using perl functions, and perl code is used to handle call-backs. Very nice because server-side functionality can utilise perl modules, such as database interfacing. Morevoer, if a user accesses the module, they see none of the DOM by looking at the source page. Also, interaction between the client and server is so restricted that a malicious user cannot send dangerous SQL statements, etc.
What happens is that a POE server is started and the browser is pointed to an internet location, where a start.xul file is located. This loads the user's module, which builds the XUL for the client and establishes a model for the server. Changes in the client state are reflected in the model, which trigger perl code supplied with the user module.
Some major and frustrating flaws.
Documentation is minimal and it takes a lot of work to understand. The tone of the documentation can be quite high-handed. In addition, the change from version 0.05 to v0.06 was not followed through completely. A file was referenced that does not exist in 0.06. However, its functionality is in another location. I used CPAN to get the missing file, only to discover it belonged to the 0.05 distribution. So I had files from both distributions. This had no material effect until I installed the POE fix (mentioned below).
The interaction with POE is flawed. Once a "model" is created, it is frozen in stone. The whole XUL-Node server needs to be killed and restarted to take into account perl script changes. A fix has been developed by the POE developers, but it was for XUL-Node v.0.05. It breaks with v.0.06. This makes the process of development and debugging very timeconsuming and irritating.
A major failing with this implementation concerns initialisation. A standard method for initialisation of UI is to link actions to the 'load' event. The problem is that when the DOM is being constructed the dimensions of the widgets are undefined. Dimensions are calculated when all the widgets are known. This occurs just before the load event. So if you need to know dimensions, eg., you want to ensure certain alignments, you have to wait until load. BUT the 'load' event is used by XUL-Node to bootstrap the whole XUL-Node DOM. So load is called to trigger XUL-Node, the DOM is built during which dimensions are undefined. But there is no subsequent load event. The work around is to trigger another 'load' event, eg., by including an invisible HTML window in the XUL-Node DOM. This is not fool-proof.
This sequence, viz. start.xul bootrapping additional DOM structure, is why the title to the window cannot be set within XUL-Node. It can be changed by modifying start.xul. Nevertheless, it is the simplicity of start.xul that hides all the functionality of the XUL-Node DOM from the causual user. In order to see the full DOM created by XUL-Node, it is necessary to inspect it using DOM-Inspector.
A serious limitation is the inability to use XBL without hacking the XUL-Node internals. A very powerful feature of XUL is the ability to design your own widgets. However, a widget in XUL, eg., <hbox> (note this is case insensitive) becomes HBox() in XUL-Node, which is strictly case sensitive. Essentially, the widget becomes a function, which is exported by the XUL-Node internals. Invent a new widget eg. <spreadsheet>, and a corresponding function name - Spreadsheet() - has to be added to the list of exports manually. There is no facility for defining the new widget in the script. Also, a new start.xul page has to be implimented with the user defined css and xbl bindings.
Finally, there is the frustration of not being able to pass parameters. XUL-Node has a parameter that is used for switching on debugging. However, I havent been able to work out how the parameter is actually trapped and used. But suppose I want for there to be some interaction between the user and the server using ordinary HTML forms, such as the selection of parameters, and then information from that interaction to be passed on to the XUL-Node script I have written. There is no way to do this.
Summary: Documentation scores 3 because it is so difficult to understand. Interface scores 3 because it is a compromise: the perl construction of the XUL DOM is a joy, but dealing with the XUL-Node server and POE is not. Ease of Use is 3 because of the need to keep killing the XUL-Node server.
XUL::Node sounds like a wonderful idea for building server side xul applications. Xul is the xml application that is used throughout most mozilla-related projects such as firefox and thunderbird. The fact that users of the application only need to have firefox to access xul applications is very appealing.
I have some issues with XUL::Node, however. An api that is more explicitly tree-like (e.g. $parent->add_child( $widget )) would seem more consistent than the current, somewhat cluttered, interface. More serious for what I would like to use XUL::Node for is that it doesn't yet implement the xul tree widget. Finally, the install is fairly heavy, (including POE).
All in all, though, a great package. I would love to see this developed further.