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

[Brett McLaughlin]

philip.nelson at omniresources.com wrote:
> 
> BTW - I am enjoying this also and appreciate your opinions, even where I
> don't completely agree ;)

;-) If we all agreed, wouldn't we be boring? Probably all sit around and
play lawn darts or something!

> 
> > > 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

+1. We're in agreement here.

> 
> >
> > > 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 ;)

Definitely! If there is one hard and fast rule, it is that there is no
one hard and fast rule ;-) As I mentioned, I'm writing an Enterprise
Applications Book (J2EE and the like), and there is so much "do it this
way here, do it that way there." The biggest problem I see in a lot of
things, like the J2EE Blueprints, is that they do exactly what you say:
they lead junior developers to thinking there is one single solution for
a task. Heck, that's why we have so many JSP people ;-)

> 
> > 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.

Now that's true - again, I think it would be overhead, but once you've
decided to use JDOM as a serialization format, then that would be my
next step as well (abstract the XML details from the client component).

> 
> > > 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

You read my mind ;-) Generation of objects, as well as DTDs or Schemas,
is great!

> 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

During production, if it is being sent and received within your
application, that's correct. Validate in test, cruise in production.
Validation is generally only left on in production if you are recieving
XML from a non-trusted source, or from user input (like an IDE).
Otherwise you pay a price for what is testable, repeatable behavior.

> XML is not used to recieve data from untrusted or unverified sources in my
> scenario.  Perhaps here we are getting off topic though.

It's all good design patterns, so I imagine people are loving it ;-)

> 
> 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.

Now that is more reasonable. So for flexiblity, you are using JDOM, but
you are "hiding" the XML representation through objects that proxy to
the JDOM document. So your client would indeed use user.getUsername(),
but the method implementation would vary. In my case, it would simply
<code>return username;</code> and in yours it might do <code>return
doc.getRootElement().getChild("username");</code> or something.

It is a middle ground; while I still don't think it's as good as
straight value objects over RMI, I can see it having some uses where
direct output is achieved through XSLT 100% of the time, or actual XML
output, and the return values over RMI map closely (80%+) to the output
seen. In those cases, you might find that over time, keeping an XML
format underneath the hood eventually pays off; and you still can
abstract your client from those implementation details.

See, I knew you weren't as far off as it seemed ;-)

Thanks for the clarification...
-Brett


-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org