• 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 ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Automating via XML. Your opinion?

 
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see a lot of code (made some myself too) that use XML to "automate" or "make it easy" programming. In example we have standalone Swing UI, that has navigation tree, and multiple pages linked to each tree node. XML may look like this:

<navitem text="Setup" page_class="somepackage.SetupPage"/>
<navitem text="About" page_class="somepackage.AboutPage"/>

The program parses XML and creates user inteface. I can write, instead:

navtree.addPage("Setup", new SetupPage());
navtree.addPage("About", new AboutPage());

For me it looks the same. The later is even better:
a) no need for fancy UI builder.
b) no reflection. Which is nice when I hit CTRL+SHIFT+G on Eclipse to find all code that uses my class. And I can safely obfuscate my JAR.
c) it's much more easy to alter individual objects.

This kind of "automation" still requires individual pages coded. I can't just change XML and it will not start working unless I provide all those classes needed. I went that "XML automation" way before but now more and more I think it's not that good. It just creates jobs In short I am now against XML that will not change application behaviour without additional coding.

I would like to ask you, what do you think on this topic? Am I right or wrong and why?

Vladas
 
Vladas Razas
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry my XML didn't make it to my post:

 
Vladas Razas
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh not again

navitem text="Setup" page_class="SetupPage"
navitem text="About" page_class="AboutPage"
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can have metadata for your screen/gui defined in database. You can generate the XML from the metadata using 3rd party tools. You can aswell realize the screen without even touching the XML route(if you have auto-generator for your gui)
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We used XML to generate Swing panels on the fly once when we had hundreds of tiny panels with a handful of entry fields on each. That avoided having hundreds of Swing panels in the classpath and loaded into memory and so on. I thought it worked out well in the long run.
 
Vladas Razas
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We had multiple panels too. It was problematic to layout components in pages using XML. I found VE (Visual Editor, Eclipse project) tool which generates code for page. So we can draw pages visually.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
XML is nice if you want to be able to change the behaviour of the system without having to recompile it - either by providing raw data, or by providing "plugin-information" (a la Dependency Injection).

It is often overused, though.
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vladas Razas:
I see a lot of code (made some myself too) that use XML to "automate" or

<navitem text="Setup" page_class="somepackage.SetupPage"/>
<navitem text="About" page_class="somepackage.AboutPage"/>

The program parses XML and creates user inteface. I can write, instead:

navtree.addPage("Setup", new SetupPage());
navtree.addPage("About", new AboutPage());

For me it looks the same. The later is even better:
a) no need for fancy UI builder.
b) no reflection. Which is nice when I hit CTRL+SHIFT+G on Eclipse to find all code that uses my class. And I can safely obfuscate my JAR.
c) it's much more easy to alter individual objects.

This kind of "automation" still requires individual pages coded. I can't just change XML and it will not start working unless I provide all those classes needed. I went that "XML automation" way before but now more and more I think it's not that good. It just creates jobs In short I am now against XML that will not change application behaviour without additional coding.

I would like to ask you, what do you think on this topic? Am I right or wrong and why?

Vladas



You are missing a major point of using XML. Externalizing data from the program offers flexibility. The module becomes open
for extension and closed for modification. It does not require re-compiling the code. Knowing how to effectively use XML is
also crucial.

In your case the implementation must automatically take the newly defined XML data and generate the GUI without requiring
any modification to the existing code.
 
reply
    Bookmark Topic Watch Topic
  • New Topic