Tag: xml

I wish the title was saying ‘And all that Jazz‘ but it is not because it is Saturday noon and I am working. At least it is from my own bed and with Ginger next to me.
The annoying thing with the recent project has been lack of design and the scope of technologies that are in use simultaneously. I have no problems working with a couple of those technologies but all at once takes away some of the concentration.
We are using an unorthodox mix of Data Access Objects (DAOs) and EJB 2.0. What we learned was that you have to watch out not using both technologies to update your precious data base tables. If you do, the EJB container locks the tables and your DAO methods start failing and rolling back to left and right.
I have previously used XDoclet to help with the formalities of EJB 2.0 and Struts framework. This time we have not taken the time (pun intended) to set up XDoclets so it is a pain every time the data model changes or the EJB implementation is updated and the interfaces need to be updated accordingly. At this point of the project, nearly end, it doesn’t make sense to start adding XDoclet tags and modifying the Ant build scripts but I have made a mental note to use XDoclets from the beginning next time.
The front-end is prepared for internalization and device independent rendering by using XML/XSL. I found that the Castor frame work is great for converting your complex Java objects to an XML representation. Later Xalan is used for the XSL transformations. One trick from the big bag of tricks is to have dynamic XSL style sheets by using JSPs. This allows us to use constants from our standard Java interfaces and to internalize our pages with the help of JSTL.
Axis framework is a great help for setting up web services for cross application wide services and sending those SOAP calls.
There has not been as much JUnit testing as we first anticipated due to lack of time. Instead of writing JUnit suits for all classes I have only written tests for core utilities that are used by several modules in the application. It was quicker to write the tests and making sure the utilities pass than to face kludgy code that would need thorough debugging.
The mix of everything is fun but just when you are getting groovy with the required on-the-fly design and UML modeling you are interrupted by some nasty JavaScript debugging or even worse, CSS problems.
I wish we find the resources to have a couple of front end developers (scary, MS Word just highlighted the last word because it found the same entry in my Outlook contacts, too smart for my liking).