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

Here's my next question.

This makes sense, but is a little too "abstract" for my taste.  Here is why.

I can understand how you would control whether to use HTML or XML or any
other decorator.  With HTML this is easy because <td> is always <td>.

But, if you want to use XML, where do you get the tag names from?  Are they
hard coded into the decorator?  If you have a vector of vectors (ie a
"table" of data) you have no way of knowing what the data actually is.
Unless of course each object in the vector element is really a data
structure with different descriptors such as field name, XML tag name, HTML
table classname, the data itself, etc...

Then I see the problem of loading the table.  You need to know all of this
stuff before hand.  And since you don't know if it's XML or HTML in the end,
you should fill in all of this information.  Add another format and you've
got more descriptors in your data structure object to worry about.

I'm just trying to think through this (actually trying to do it) and
reaching these roadblocks.

Brad

 

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
> Sent: Tuesday, March 06, 2001 5:36 PM
> To: JAVA400-L@midrange.com
> 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.
> 
+---
| 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
+---