[jdom-interest] Re: EJB Mapper (was Newbie: JDom-Test)

[philip.nelson at omniresources.com]

BTW - I am enjoying this also and appreciate your opinions, even where I
don't completely agree ;)


> > How are you paying both prices?  If the document was 
> constructed in memory
> > and sent over as a serialized JDOM document, there is no 
> parse.  If the
> 
> Because every time you create any single construct in memory in JDOM,
> you pay an XML-specific price. The name of the element, the attribute,
> the data, the values, it's all parsed, character by character, and
> verified to be legal XML. Creating a JDOM Document just because it's a
> structure you like is fine, I suppose, but you have to realize that it
> is a lot more expensive than creating a custom structure 
> without all of
> these various checks occurring.

Yes you have to account for the extra overhead.  Is it worth it? depends

> 
> > document was constructed originally from and XML document 
> for legitimate
> > reasons (like an use with an external system), you only 
> have the one parse.
> 
> You parse it going in; there, there are two prices, both parsing and
> serialization.
> 
> No matter how you cut it, serializing a JDOM Document pays (1)
> serialization costs and (2) medium-to-high XML costs, 
> depending on if it
> was created in memory (medium) or created from an XML document (high).
> 
> I'm not saying you can't do this - I'm saying for Java-to-Java RMI
> communication, it's a poor choice without a /really/ good reason. It
> works fine in many other situations.

This is exactly what I'd hoped you would say! What I worry about is blanket
statements like "you should always write a custom value object" that leads
junior programmers into design paralysis and with me having to contradict
well respected experts like yourself.  What you are saying is right more
often than not ;)

> user.getUsername();
> 
> than to have to somehow pass on to your client component
> 
> document.getRootElement().getChild("username").getValue();

Again, I agree but I could take care of this by making the JDOM document
invisible to the external interface.

> > Absolutely.  My current project deals with thousands of 
> electronic forms.
> > These forms vary from year to year.  Forms are added and 
> dropped constantly.
> > The validation rules change constantly.  Adding a hand 
> coded value object
> > for each of these would be a tremendous burden on my most 
> scarce resource,
> > programmers.  I am constantly looking for ways to eliminate 
> code that varies
> 
> You've got to be kidding! If you're doing solid XML programming, then
> you are writing a DTD for each one. And I simply don't 
> believe that it's
> easier to write a DTD for even a midly-complex form than to 
> code a value
> object. Additionally, if you are using EJB, then you already 
> have had to
> code the value object. ANd if you're not using DTDs, then 
> that's a whole
> other story ;-) You're allowing incorrect (invalid) data to be
> proliferated through the system.

I only need 1 DTD and will only use it during development.  This is why I
like XML: the flexibility to vary the format without breaking code.  Even if
I did need a separate DTD, it would be generated from the same source that
produces my XML.  I suppose that I could generate my value object too
though.  The rules about valid data are way beyond the capabilities of a dtd
so there is a separate rules engine for that part. I have seen others report
that validating with a DTD will not normally be turned on.  Remember, the
XML is not used to recieve data from untrusted or unverified sources in my
scenario.  Perhaps here we are getting off topic though.

I hope someone else pipes in here.  I am not actually sending JDOM documents
over RMI at this point.  I am using JDOM documents to hold data inside a
business object that must interact with databases and external systems via
XML.  I just think it is an interesting middle ground to your value objects
and full parsing of XML strings which I have thought would only work in low
to moderate hit parts of my applications.