RE: HTML to XML, vice versa

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

I highly suggest the book "Design Patterns" by Gamma, Booch, et al.  You can
find it here:

http://www.amazon.com/exec/obidos/ASIN/0201633612/102-3992014-1861707

The concepts of Factories, Decorators, Singletons and so on are fundamental
to object oriented programming, and the book does a far better job of
explaining them than you'll get from a medium as simple as this forum.

That being said, let me try to get you to the gist of the idea:

First, a "table" is an abstract notion.  When I use the term "table" in
describing data, don't think about HTML or XML or anything.  Just think
about the structure.  In general, a table is a set of rows, and rows contain
cells, and cells contain data.  In either an XML or an HTML representation
(and many other representations), this model is the underlying structure of
the data.  In OO programming, you think of underlying structure, not end
products.

Now, I need to think how to translate this abstract data structure to the
specifics of an HTML representation.  A typical procedural approach might be
to code a loop that outputs first "<table>", the reads through a Vector of
Vectors that contain the data.    For the outer loop, I would output "<tr>",
then read through the inner Vector.  For each element in the inner loop, I
would output "<td>" followed by the contents of the data element, followed
by "</td>".  After finishing the inner loop, I'd output "</tr>".  After
finishing the outer loop, I'd output "</table>".

Perfectly reasonable, and similar to what most CGI type programs do.  In an
OO environment, things are different.  I create an AbstractWidget class and
from that I derive an AbstractTableWidget class.  The AbstractWidget is the
parent of all widgets, and its job is to hold certain global information and
routines.  Most importantly, it holds the pointer to the "Formatter" object,
which is really the Factory.  The AbstractWidget provides utility methods
such as converting Strings to Vectors and vice versa, stuff like that.

The AbstractTableWidget actually implements the Decorator pattern, in that
its job is to take a data source and format it as a table.  He cycles
through the data, mostly by calling abstract methods which are actually
implemented in the subclass.  But his job is to take some form of structured
data and turn it into some sort of table widget.  The subclasses determine
the type of data being converted, and how the are transformed.

What subclasses?

Well, I subclass the AbstractTableWidget to do more specific functions.  In
my design, I have a different subclass for each different data source.  One
data source is a set of records read from a query server.  Another data
source is a single record read from a CRUD server.  Either one can be mapped
to the concept of a table.  Both follow a general format of table header,
table rows, table trailer.  Each formats the data a little differently, but
both need to eventually format some sort of ML (markup language) tags.
However, whenever one of these classes goes to actually format some ML, they
always use the Factory object (the formatter, which we stored way up in the
AbstractWidget class).

Remember the AbstractWidget?  Well, he comes into play again.  Whenever I
actually go to generate the String information to be output to the browser,
I call the toString() method of the AbstractWidget.  This is turn causes the
subclass to generate itself on the fly.  Up until this point, there has been
no calls to the Factory, so, if I were to simply change the formatter to the
XML Factory rather than the HTML Factory, I would get an XML representation.
In fact, I could change the Factory, call the toString() method, then change
the Factory and call the toString() method again.  In that way, I could get
two different representations, quite easily.

And that is the basic work of a Decorator and a Factory.  A Decorator adds
information to a data structure, a Factory returns different types of data
for the same thing, depending on the representation desired.  Combine the
two and you have a flexible data translation system.

BTW, the "switch" is simply which object has been attached to the widget.
The AbstractWidget has a method with the following signature:

public void setFormatter(AbstractFormatter formatter)

This stores a pointer to a formatter object in the widget.  Whenever I go to
call the formatter, I execute the method getFormatter() to get the current
formatter object.  In my case, I also have a systemwide default formatter,
so that if you don't define one, the default formatter is used.  In the
current package, the default is the HTML formatter.

> -----Original Message-----
> From: owner-java400-l@midrange.com
> [mailto:owner-java400-l@midrange.com]On Behalf Of Stone, Brad V (TC)
> Sent: Tuesday, March 06, 2001 4:15 PM
> To: 'JAVA400-L@midrange.com'
> Subject: RE: HTML to XML, vice versa
>
>
> Thanks for the offer, Fred.
>
> Would some small code snippets be easy to show?  Even if they don't deal
> with html or xml, just something to show how a factory or decorator class
> works.  This is where I'm having a hard time understanding how it would
> work.
>
> I get this much... that a table has a table header (<table>) and a table
> trailer (</table>).
>
> What I don't understand is how at runtime you're going to "plug
> in either an
> HTML factory or an XML factory".  Why this is confusing is because XML
> doesn't contain "tables" per say.  I'm also having a hard time
> understanding
> how this is "plugged in" as to me it seems reasonable that there has to be
> something somewhere, a switch, an atrributre, or something to "tell" it
> which factory to use.
>
> The terminology of "factory" and "decorator" class is also new to me.  My
> idea of these is that the factory is what produces the final product (ie
> HTML or XML tags).  But, what does the decorator class do, and how is it
> invoked?  That's why seeing some simple examples would help my procedural
> mind grow.  :)
>
> Thanks again!  This should make some good archive info!
>
> Brad

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