Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Dynamic vs. Static STRUTS forms...

Ranch Hand
Posts: 238
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Saloon Keeper
Posts: 24894
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic