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

So, in a basic sense, here's what I got from these great explanations....

I'm thinking too much of HTMl or XML tables.  A table "object" in Java is
like a 2dim array (or vector of vectors) that holds the data as it _would_
be displayed.  Then, since I have "raw data" in this form (which is the
factory?), I can call methods using this object to display the data any way
I want (using the decorator?).

Close?

Brad

> -----Original Message-----
> From: Joe Teff [mailto:JoeTeff@earthlink.net]
> Sent: Tuesday, March 06, 2001 6:05 PM
> To: JAVA400-L@midrange.com
> Subject: RE: HTML to XML, vice versa
> 
> 
> Applause. I liked your explanation.
> 
> Factory is a term used to describe a class/method that 
> creates and returns
> an object to you. This makes the creation of the object 
> "soft-coded" and
> more easily changed. JDBC connections is an example.
> 
>    con = 
> DriverManager.getConnection("jdbc:as400://99.0.255.10", "JUSTME",
> "LETMEIN");
>    con = DriverManager.getConnection("Jdbc:Odbc:myLibrary");
> 
> The Connection object returned by the two statements above 
> are different.
> They were both created from classes that implemented the Connection
> interface though. The static method 
> DriverManager.getConnect() is a factory
> method. It creates and returns objects.
> 
> Patterns are really just design therories or templates. We've 
> had them in
> all languages really. DFUs are really an implementation of the "Table
> lookup/display/maintain" pattern. Don't look for this 
> pattern, I just made
> it up :)  OO has coined the term is all. They've also 
> published books that
> describe various patterns. This isn't new for Java.
> 
> Joe Teff
> 
> -----Original Message-----
> From: owner-java400-l@midrange.com
> [mailto:owner-java400-l@midrange.com]On Behalf Of Joe Pluta
> 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.
> 
> > -----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
> +---
> 
+---
| 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
+---