RE: HTML to XML, vice versa -- JAVA400-L


Brad Stone wrote:

>To me, this really seems like a fancy way of hardcoding.  :)   If we make
a
>decorator object for every field in our system that's a lot of decorators.
>Now, multiply that number by every *ML tag we want to use.  Yikes.

True.  But, the question really would turn out to be "where does the
hardcoding go and how does one maintaint it?"

In my later examples I was going beyond output per se and trying to reflect
an underlying reailty.

XML is different from HTML.  In fact, what is likely to happen is that many
designs that today deal with records, one at a time, will instead deal with
XML "trees" that are kind of like records and kind of not.

So, internal to the Java program, the "natural" representation will be as a
tree of Java objects.  Processing will consist of walking up and down this
tree until the item of interest is found.

The question of "decorators" would arise primarily when it came time to
export this tree to some useful format.  This would be either an XML
document (to enable the tree to be simply reconstituted later) or to HTML
to produce output for the web.

Now, in point of fact, there is a whole separate thing called XML Style
Sheets that solves this problem without programming.

But, as a concise business example, this is still pretty good.

The issue here is "who owns what" and "who maintains what" and even "how
many times is it coded."

Certainly, the way things are described, this looks like, and is, a lot of
work.  But, any real application that exported to HTML faces all the
problems we're describing.

Moreover, the choice of "how" to export an address1 (or any other XML tag)
as an element of an HTML table is not immediately obvious in detail.  Do
you have a need to use a fixed font?  Should the address always be red?  Is
it actually better to render it as a small table within a table?  Is there
an ordered list of sub-pieces?  An unordered one?  For address1, these are
fairly easy to answer.  But, there will be XML tags for which this is not
as obvious.  I wouldn't want to distribute the answers to these questions
all over the code.

These are, in short, the sorts of questions that the individual HTML
decorator object can answer in arbitrary detail.  Moreover, if the design
is divided as we've recently suggested, the separate object means the kind
of information is not present in the base "address1" type object where it
doesn't belong.  Or, in the nonJava case, scatttered throughout a bunch of
procedural code.  If we didn't do this, the knowledge I'm talking about may
end up scattered everywhere we want to do ToHTML, which might be more than
one place after all.

And, because all this hardcoding is specific to "the HTML decoration of an
address1 tag", a lot of things do end up hard coded.  But, these
hardcodings also end up centralized and easy to change.  While it can be
long and tedious in some circumstances to make all these objects, once it
is done, it can be reused several times, maybe even within the first
release of the same project.  You don't, in other words, have to distribute
all this dreary detail all over the code.  And, if it must be changed, you
go to one place to change it without drastically affecting who knows how
much code.

When you're done, these classes will act like old style assembler language
macros.  They will be brief, easy to get correct, and logically (or even
actually) included where invoked.

Another potential here is that address1 is too low a level of granularity.
Maybe the employee tag would be the lowest granularity of decorator object.
But, I doubt if that really saves as much work as one might think.

I would also be remiss not to point out that, in a lot of real world cases
like this, where there are dozens and dozens of entities, they can also
have at least the first pass of their Java source created by a faily
simple-minded source code generator.  A kind of quick-and-dirty poor man's
wizard.  I've used this with success, creating all the dreary boilerplate
that's probably bothering you and leaving on the substance (which has to be
coded somewhere) as the only thing I end up doing by hand.  These
generators are sometimes so simple, I've been known to write them in old
fashioned DOS Basic.


Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN
--
We must do a few things well, rather than everything late.
8-553-3535   (507) 253-3535

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---