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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
