|
||||||||||
Wiki : 
| HomePage :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register |
Most recent edit on 2008-05-08 07:51:29 by LuanO
Deletions:
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link∞.
Edited on 2008-01-07 13:37:20 by ValCas
Additions:
Edited on 2008-01-07 13:36:46 by ValCas
Additions:
Deletions:
<a name=projectteams> </a>
Edited on 2008-01-07 13:36:17 by ValCas
Additions:
<a name=projectteams> </a>
Edited on 2008-01-07 10:20:22 by LuanO
Additions:
This is demonstrated in the following video tutorial∞
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.
Page navigation and application logic are demonstrated in the video tutorial∞
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link∞.
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.
Deletions:
This is demonstrated in the following video tutorial http://www.xoetrope.com/xui/tutorials/editorintro/comps∞
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. 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.
Page navigation and application logic are demonstrated in the video tutorial at http://www.xoetrope.com/xui/tutorials/editorintro/navigation∞
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link http://www.xoetrope.com/resources/carouselcrm/outlook/flash/outlookpresentation.html∞
An example of this in action can be seen at http://www.xoetrope.com/resources/xui/video/MedicalClinic/MedicalClinic.html∞. 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.
Edited on 2008-01-07 10:16:31 by LuanO
Additions:
Return to the Evaluator's Guide
Edited on 2008-01-04 13:06:00 by ValCas
Additions:
An example of this in action can be seen at http://www.xoetrope.com/resources/xui/video/MedicalClinic/MedicalClinic.html∞. 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.
Edited on 2008-01-04 12:57:22 by ValCas
Additions:
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∞" ).
Edited on 2008-01-04 12:53:07 by ValCas
Additions:
An example of migration of a Visual Basic application can be viewed at (to be done).
Edited on 2008-01-04 12:02:48 by ValCas
Additions:
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link http://www.xoetrope.com/resources/carouselcrm/outlook/flash/outlookpresentation.html∞
Deletions:
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM.
Edited on 2008-01-04 11:58:09 by ValCas
Additions:
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.
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM.
Edited on 2008-01-04 11:34:02 by ValCas
Additions:
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.
Edited on 2008-01-04 11:18:04 by ValCas
Additions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. 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.
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.
Deletions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. Styles can be
Edited on 2008-01-04 11:11:49 by ValCas
Additions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. Styles can be
Deletions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞
Edited on 2008-01-04 11:09:31 by ValCas
Deletions:
Edited on 2008-01-04 11:09:11 by ValCas
Additions:
Edited on 2008-01-04 11:08:54 by ValCas
No differences.
Edited on 2008-01-04 11:08:41 by ValCas
No differences.
Edited on 2008-01-04 10:29:28 by ValCas
Additions:
<Image name="nextButton" x="564" y="51" w="19" h="18" content="right.gif"/>
Deletions:
<Components>
<Events>
Oldest known version of this page was edited on 2008-01-04 10:29:01 by ValCas []
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.
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.
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.
This is demonstrated in the following video tutorial http://www.xoetrope.com/xui/tutorials/editorintro/comps∞
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.
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞
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.
Page navigation and application logic are demonstrated in the video tutorial at http://www.xoetrope.com/xui/tutorials/editorintro/navigation∞
Deletions:
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link∞.
Edited on 2008-01-07 13:37:20 by ValCas
Additions:
Edited on 2008-01-07 13:36:46 by ValCas
Additions:
Deletions:
<a name=projectteams> </a>
Edited on 2008-01-07 13:36:17 by ValCas
Additions:
<a name=projectteams> </a>
Edited on 2008-01-07 10:20:22 by LuanO
Additions:
This is demonstrated in the following video tutorial∞
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.
Page navigation and application logic are demonstrated in the video tutorial∞
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link∞.
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.
Deletions:
This is demonstrated in the following video tutorial http://www.xoetrope.com/xui/tutorials/editorintro/comps∞
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. 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.
Page navigation and application logic are demonstrated in the video tutorial at http://www.xoetrope.com/xui/tutorials/editorintro/navigation∞
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link http://www.xoetrope.com/resources/carouselcrm/outlook/flash/outlookpresentation.html∞
An example of this in action can be seen at http://www.xoetrope.com/resources/xui/video/MedicalClinic/MedicalClinic.html∞. 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.
Edited on 2008-01-07 10:16:31 by LuanO
Additions:
Return to the Evaluator's Guide
Edited on 2008-01-04 13:06:00 by ValCas
Additions:
An example of this in action can be seen at http://www.xoetrope.com/resources/xui/video/MedicalClinic/MedicalClinic.html∞. 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.
Edited on 2008-01-04 12:57:22 by ValCas
Additions:
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∞" ).
Edited on 2008-01-04 12:53:07 by ValCas
Additions:
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).
Edited on 2008-01-04 12:02:48 by ValCas
Additions:
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM. The result is a XUI based application which mimics the look of the SugarCRM system. And now because it runs on the client, users can take their data on the road with them and synchronize when they get a connection again. Not only that, but they can also begin to work with their desktop as can be seen in this link http://www.xoetrope.com/resources/carouselcrm/outlook/flash/outlookpresentation.html∞
Deletions:
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM.
Edited on 2008-01-04 11:58:09 by ValCas
Additions:
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.
For an example of what this transformation can do have a look at the CarouselCRM application which is generated from an existing SugarCRM installation. SugarCRM is a PHP, MySQL and HTML CRM system. It suffers from the usual limitations of brower based applications like slow response, dependance on the server and lack of integration with the desktop. In order to generate the XML that drives the RIA user interface for CarouselCRM, it was possible to parse the HTML that defines the SugarCRM system. You might be wondering why it isn't just generated once and deployed. This is because it's possible for the SugarCRM administrator to customize the pages and add new fields. Because this can't be predicted, it's necessary to generate the pages for each implementation of SugarCRM.
Edited on 2008-01-04 11:34:02 by ValCas
Additions:
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.
Edited on 2008-01-04 11:18:04 by ValCas
Additions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. 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.
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.
Deletions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. Styles can be
Edited on 2008-01-04 11:11:49 by ValCas
Additions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞. Styles can be
Deletions:
This is demonstrated in the next video tutorial step http://www.xoetrope.com/xui/tutorials/editorintro/styles∞
Edited on 2008-01-04 11:09:31 by ValCas
Deletions:
<XPage> </XPage>
Edited on 2008-01-04 11:09:11 by ValCas
Additions:
<XPage> </XPage>
Edited on 2008-01-04 11:08:54 by ValCas
No differences.
Edited on 2008-01-04 11:08:41 by ValCas
No differences.
Edited on 2008-01-04 10:29:28 by ValCas
Additions:
<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"/>
<Events><Event method="nextPage" target="nextButton" type="MouseHandler"/>
<Event method="prevPage" target="prevButton" type="MouseHandler"/>
</Events><Event method="prevPage" target="prevButton" type="MouseHandler"/>
Deletions:
<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><Image name="prevButton" x="60" y="54" w="19" h="18" content="left.gif"/>
<Events>
<Event method="nextPage" target="nextButton" type="MouseHandler"/>
<Event method="prevPage" target="prevButton" type="MouseHandler"/>
</Events><Event method="prevPage" target="prevButton" type="MouseHandler"/>
Oldest known version of this page was edited on 2008-01-04 10:29:01 by ValCas []
Page view:
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 http://www.xoetrope.com/xui/tutorials/editorintro/comps∞
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 http://www.xoetrope.com/xui/tutorials/editorintro/styles∞
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() {
}
}Page navigation and application logic are demonstrated in the video tutorial at http://www.xoetrope.com/xui/tutorials/editorintro/navigation∞
Generating from metadata
Generating from a HTTP connection
Roles
Styles
Page was generated in 0.7517 seconds