RE: HTML to XML, vice versa

Brad Stone wrote:

>But see, Im having a hard time with it because the alignment, width and
>contents fields are all really something nasty looking.  So, it would look
>something like this:
>
>String outputstuff = otherstuff +
>    (new XMLTDWrapper(myClassList.getField(i).status.alignment,
>                      myClassList.getField(i).status.width,
>                      myClassList.getField(i).status.data)).toString();
>
>Which means I have to subset "MyClass" yet again to include attributes of
>each field from the field (when before .status simply contained the data
>itself).  Makes it even more harder to follow.
>
>I think it's cool, but would I want to do a whole system like this?
Yikes!
>This system I'm working on now is just 1/100000th of the entire system.
>
>Am I alone in what I'm thinking?  I know I'm wet behind the ears, and I
want
>to (and will) go deeper, but man.  This is a lot of work for a "real"
>application.

Hmm.  I think I have lead you seriously astray here.  There is a kind of
"meta-rule" of O-O that
I find helpful; if you're passing around a lot of parameters, something is
wrong with the O-O design.
Here, that would be my design, not yours.

It is actually somewhat hard to do a proper O-O decomposition on a list
server like this,
where one gets to pay only intermittent attention over several days, but
let me keep trying.

Even though it was a response to a later note (I think), let's pursue a
'decorator object' and
an 'actual object' approach here.

Now, if we're talking about having some sort of HTML table that gets
converted to XML, then
it would appear that we'll need some obvious objects:

TD, TR, TABLE

But, since XML has "meaning," just as do fields in a DB, we'll also need
some
actual fields that correspond to whatever the table
we're converting "really mean."  In my example of an
"employee record" that was (for some reason, per hypothesis)
expressed as HTML, that means that TD number one would always
be the employee name, TD number two would be the
employee number and so on.

So, all the tags I gave before:

employee, name, employee_number, address1, etc. would also be objects.

Now, one under-discussed approach would be to have a toXML and toHTML
method
defined for each of these objects.

That might not be best, however.  What we might want is the approach we've
been
dealing with, that has a "decorator" object that corresponds, one-to-one,
with the various
"real" objects.  This does appear to have some flexibility; new
"decorators" could
be defined without disturbing the "main" objects much if at all.

Now, that means that, in fact, the TD, TR, TABLE kinds of objects are
really just the
HTML versions of specific decorator objects.  There would be an
address1HTMLDecorator
object that happens to put out a <TD> and </TD> as part of its output.

That would give this correspondence:

  address1ToHTML   <--->  address1  <---> address1ToXML

and two different "factories", one each for HTML and XML.  There would be
similar
sets for all the other tags (employee, number, etc.).

A really smart design might have some sort of commonality between all the
"decorator" types, which would mean the potential for an even more generic
"factory" approach.

Note that in this scheme, TD,TR, and TABLE disappear as individual objects
after all.

The main problem with this approach is the one you've already identified.
The
"decorators" may have to access most of the interesting contents of their
corresponding
objects.  That will lead to ugly little routines with way too many
parameters.

Now, for the case of TR type objects (e.g. employee), which
are basically list objects, this is actually going not be a problem,
thanks to O-O polymorphism, but the problem will certainly
exist in spades for the "detail" objects.

The virtue of such an approach would be that truly "decorator" functions
could
be split out of the object proper.  The real value of this design, in other
words,
would be if address1ToHTML could somehow manage width _on its own_ without
simply accessing a getWidth() function in the address1 object.

In other words, you really want to see something like:

  outstring = outstring +   (new address1ToHTML(address1_ref)).toString();

In other words, the constructor for the "decorator object" takes on
its corresponding "real" object as its constructor parameter.  A "factory"
interface
would work similarly, except you'd pass in a more generic object that would
select the correct constructor.

   outstring = outstring +  (GenerateToHTML(someEmployee_ref)).toString();

If all decorators can have a common parent, this might even be:

   outstring = outstring +
     (GenerateDecorator(someEmployee_ref,"HTML")).toString();

The question of "what did this kind of constructor buy you"
would revolve around the question of "how often does
the constructor of address1ToHTML invoke getWidth()
and getAlignment() after all."   But, the answer to that might conceivably
be "never at all."

In not a few cases, these could be constants and, thankfully,
not part of the address1 and like objects at all.  In ToXML, this is less
strictly
to be true, because attributes in XML typically aren't about 'alignment'
but more about things like 'what country is this address within'.  Still,
even there,
there is the opportunity for the various ToXML and even ToHTML objects to
do the nontrivial part of the calculations.  Instead of just fetching a
width, in
other words, they fill in a constant or calculate its value.  This would
not
just reduce the parameter count; it would represent a better O-O design,
because the important entities (e.g. width) are associated with the right
object (e.g. xxxToHTML versus the base xxx object).

In any event, you want to get most of the parameterization into the
constructor
and out of the individual methods.  Here, because the decorators may be so
short lived, there may be less advantage to it compared to usual.



Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN


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