Re: HTML to XML, vice versa

Joe,

Have you ever seen a Java-centric version of this worthy book?

Trying to mentally translate the differences between C++ and Java might
prove to be too much for someone just learning OO.


John Taylor
Canada


----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <JAVA400-L@midrange.com>
Sent: Tuesday, March 06, 2001 16:36
Subject: RE: HTML to XML, vice versa


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

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