Which is more efficient, Dynamic forms defined in the struts-config file or coded .Java forms? To me, it makes more sense (on a large scale application, anyway) to have the forms actually coded in java vs. having a 1 meg xml file for processing forms for inquiries and such. Our team is using both, but, as maintenance is handed off to another group in the future, the potential to screw somthing up by using the Dynamic approach would increase in time while having the individual forms coded would only lead to one form (or form family) being affected if somthing was wrong (at maintenance time). Does this make sense ? I would be greatful for any advice from anyone who has had to deal with this type of issue. Thanks!
Funny you should say that. Informal observation has just about convinced me that the most efficient way to ship a Java program is as source code, as the classfiles seem to be large than their sources. Maybe old news to some, but I catch on slow. Working with a lot of different GUIs over the years, my experience is that declarative GUI definition has two advantages: 1) the declarations typically are physically smaller than programmatic code. 2) because the declaration syntax is usually simplistic, it requires less labor to get results and it's easier to define automated validators. The presumed advantages of programmatic GUI over declarative are that you potentially have more flexibility and would presumably be more effcient, since you'd only invoke services as needed rather than by rote. Java Swing's performance does make me pretty cynical on that, though. XML is declarative, but not the world's tersest notation. It also requires a fairly heavy-duty decoder if you want to interpret the XML GUI at each execution (as opposed to generating code). Size isn't that much of an issue. Most XML has a lot of redundancy in it and thus will compress well. Compressed XML is becoming quite a popular way to go on open-source projects. Compare the size of a Star Office document file (zipped XML) vs. the same document in Microsoft Office format and you'll be amazed at how much smaller the StarOffice doc is, despite being expandable to human-readable text. What about the extra overhead for compression? Good question. Quite a few years back the company I worked for ran some benchmarks and discovered that there was actually less CPU overhead involved when their system worked with compressed records than when it had to shuffer around full-sized buffers. Actual mileage may vary, of course. Both CPUs and I/O hardware are a lot different now, so I'd benchmark before betting the farm. It may have gotten worse. Or better.
Customer surveys are for companies who didn't pay proper attention to begin with.