aspose file tools*
The moose likes Struts and the fly likes Dynamic vs. Static STRUTS forms... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Dynamic vs. Static STRUTS forms..." Watch "Dynamic vs. Static STRUTS forms..." New topic
Author

Dynamic vs. Static STRUTS forms...

Sam Smoot
Ranch Hand

Joined: Apr 18, 2002
Posts: 238
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!


CNSS/NSA Infosec Professional,<br />Software Engineer
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16068
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Dynamic vs. Static STRUTS forms...