My impressions of Turbine + XML/XSLT

[Luke Holden <al...@prodigy.net>]

I have been working with turbine for a month or two now... and have learned a 
great deal. I thought some of you might be interested in my experiances.

Right now I am designing an application for a customer of mine. Lucky I got 
the choice of application environment. Due to the fact I am totally in love 
with Java I descided that the project definatly had to be a java servlet.

I have played with turbine a bit in the past, so I descided to use it as the 
application frame work for my application.

The environment looks a bit like this

Caucho Resin servlet/JSP app server (www.caucho.com)
Java 2 1.4rc (1.4 release will be out when the project hits production)
TDK 2.1 with a newer version of Turbine (and friends) that I compiled my self 
(The version of turbine included in the tdk is a bit buggy... the UIMananger 
gives a bad url for images... for example)

Although I started off using the default velocity+html for generating the 
screens/layout... I descided to move to XML and XSL.

I modified the included VelocityXslLayout and created a VelocityXslScreen.

the XML files are all velocity processed. The XSL files are static.

Basically the navigation and layout are combined into the layout XSL file... 
which works out pretty well. The XML data for navigations all merge into the 
layouts XML data for translation.

The screens are actually being transformed into XML via XSL and inserted into 
the layouts XML data under the <screen> tag. Which is then transformed into 
html with the layout.

I do not know if this is the most efficient way to do things... but it seems 
to work pretty well for me.

I have found that having my design totally seperate from any functionality 
(read: velocity code) makes things really easy. All I have to do is define 
the data model for a screen (which btw... all screens follow the same basic 
data model) and the designer can figure out any way she pleases to actually 
render that data.


I love the seperation of logic and design this gives me. It allows me to 
change both the pull tools and how the data is generated... and as long as 
the data model comes out the same, the designer does not have to be bothered 
with anything.


A great side effect of this is the ability to make parts of the design truely 
generic.

I have two main generic XSL translations. One for form matrices and one for 
table matrices. The generic form matrix handles things from the login 
screen.. to all the flux form screens. The table matrix handles things like 
displaying the search data to displaying the Flux lists.


I think that about covers things. If anyone has any questions reguarding 
anything I am using, please feel free to ask.

Also, because I am a geek and love showing off... I have some screenshots 
demoing the application and some of the features I mentioned.

You can find them at:

http://www.webmastersmall.com/~luke/compass/

I would provide a url to the application, but it is far from finished and is 
not on a public server. Also note.. the actual layout/design of the 
application is VERY far from what it will look like once it hits production 
status. 

Luke

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>