Wiki: Authoring

Authoring

The clean default MVC separation of XUI projects means that elements of a GUI application can be isolated more easily. For example the styles are stored in their own style file or series of style files. The page components are laid out from XML without the need for any Java code. This means that these elements can be manipulated or generated without so much dependancy on the other elements of the application.

Project Teams

The flexibility gained from the separation and XML driven nature of XUI Applications means that applications can be created in a number of ways, which may otherwise have been prohibitively difficult.

Visual Editing

This is the most basic and easiest way to create XUI applications from scratch. The plug-ins for NetBeans and Eclipse allow you to create your applications in the familiar WYSIWYG way. You create your pages and drag and drop components from the palette. This is pretty usual stuff except for that fact that behind the scenes XML is being created and not Java code. This is where the clean separation begins. You will immediately appreciate the fact that your Java code isn't polluted with lines telling you what you can and cannot edit in your classes. This code snippet illustrates what's created as you build your page.

<XPage>
  <Components>
	<Label x="123" y="51" w="100" h="20" content="Title:" />
	<ComboBox x="238" y="51" w="100" h="20"/>
	<Label x="123" y="80" w="100" h="20" content="Firstname:" />
	<Edit x="238" y="78" w="178" h="20" alignment="Leading"/>
	<Label x="123" y="110" w="99" h="20" content="Surname:" />
	<Edit x="238" y="106" w="178" h="20" alignment="Leading"/>
  </Components>
</XPage>

This is demonstrated in the following video tutorial∞

Styles are also created within the editor and the XUI Color Wheel allows for some very advanced styling techniques. The styles are generated into a separate style file in XML format. This means that an application can be handed to a grapical designer who can then take care of modifying the styles without having to write code and without having to recompile the application. So following from the previous snippet the following code illustrates what the style file looks like and how the styles are applied to the components.

<styles>
  <style name="prompt">
	<color_back value="ffffff"/>
	<color_fore value="0000aa"/>
	<font_face value="arial"/>
	<font_size value="12"/>
	<font_weight value="0"/>
	<font_italic value="0"/>
  </style>
  <style name="prompt">
	<color_back value="ffffff"/>
	<color_fore value="000000"/>
	<font_face value="arial"/>
	<font_size value="12"/>
	<font_weight value="1"/>
	<font_italic value="0"/>
  </style>
</styles>

<XPage>
  <Components>
	<Label x="123" y="51" w="100" h="20" content="Title:" style="prompt" />
	<ComboBox x="238" y="51" w="100" h="20" style="data"/>
	<Label x="123" y="80" w="100" h="20" content="Firstname:" style="prompt" />
	<Edit x="238" y="78" w="178" h="20" alignment="Leading" style="data"/>
	<Label x="123" y="110" w="99" h="20" content="Surname:" style="prompt" />
	<Edit x="238" y="106" w="178" h="20" alignment="Leading" style="data"/>
  </Components>
</XPage>

This is demonstrated in the next video tutorial step∞ . Stylesheets for different audiences can easily be swapped. This can be useful in instance where you might want to push applications out to users via webstart or applets but want to brand according to the target company.

When you do want to hook up some Java application logic to the page the XUI editor will take care of creating the page Class and associating it to the page XML. You still manipulate the components styling and layout without having to touch your Java code. Much of the plumbing associated with developing GUI applications is removed by XUI allowing Java developers to concentrate on what's most important to them - coding business logic. The XUI API allows provides developers with a host of mechanisms for component construction, styling, navigation, resource loading etc. The following code snippet demonstrates how this associate is created.

<XPage class="net.xoetrope.mortgage.NavPanel" style="Heading">
  <Components>
	<Image name="nextButton" x="564" y="51" w="19" h="18" content="right.gif"/>
	<Image name="prevButton" x="60" y="54" w="19" h="18" content="left.gif"/>
  </Components>
  <Events>
	<Event method="nextPage" target="nextButton" type="MouseHandler"/>
	<Event method="prevPage" target="prevButton" type="MouseHandler"/>
  </Events>
</XPage>

package net.xoetrope.mortgage;

import net.xoetrope.xui.*;

public class NavPanel extends XPage
{

  public void nextPage()  {
  }

  public void prevPage()  {
  }
}

As can be seen from this snippet, there is no need to create the component events in the Java class. This is taken care of for you by the simple XML declaration. Any page which is bound to an XML page must extend the net.xoetrope.xui.XPage class.

Page navigation and application logic are demonstrated in the video tutorial∞

Generating from metadata

Declaring a user interface in XML has already shown itself to be a very flexible mechanism for separating the bulk of page construction from the main codebase. Where it really comes into it's own is where you might have an existing set of metadata describing an application. The source of this metadata is pretty much irrelevant. What's important is that it can be converted easily into XML. The result is a Rich Internet Application which can be generated from an existing set of metadata or from legacy applications.

Migrating legacy applications

Another very flexible use of the XML format is to transform legacy applications. We are aware of work being carried out to convert Visual Basic, Delphi and Oracle Forms applications. With these formats it's relatively straightforward to convert the screens to the XML format and also to capture the style information. Even creating the events with the XPage Java stubs can be done. It gets trickier when the code itself needs to be converted. Xoetrope are currently working on a more complete migration of entire Oracle Forms.

An example of migration of a Visual Basic application can be viewed at (to be done).

Generating from a HTTP connection

In some cases it might be necessary to serve up the XML directly from a HTTP connection. This means that the pages can change from one render to the next. This is achieved by specifying a URL for the pageManager to load. So instead of pageMgr.showPage( "customer" ) you would have something like pageMgr.showPage( "http://[host]/[app]/getpage?page=customer∞" ).

An example of this in action can be seen here∞ The user interface for this application is generated from a Zope / Plone back end. The components declarations and data models are sent to the client which means that the application can be changed to capture new fields without having to recompile and deploy a new application. Updates are reflected on the client simply by modifying the metadata.

Roles

Many projects suffer from the different approaches of the members of the development team. These projects typically start off with some good architectural design but this can be a difficult discipline to maintain over the lifetime of the project. Changes within the development team means that unless the architecture is well documented and followed, changes can easily begin to fall outside of the initial design. This is usually made worse by the demands of the business. The result is a project which becomes difficult to maintain and enhancements take much longer that they should.

Because XUI creates MVC applications by default, this struggle to create well structured applications is reduced significantly. What's more, it's a mature and stable platform that has been developed by many software engineers with many more writing real world applications. This means that you can rest assurred that the approaches have been tested and proven over and over again. XUI promotes a best practice approach to application development without restricting the developers use of the Java platform

Of course, XUI won't remove the need for best practice approaces but it will help to define them.

Styles

Return to the Evaluator's Guide

Wiki : Authoring