|
Java Design Patterns by James W Cooper ISBN 0-201-48539-7 Joe Teff -----Original Message----- From: owner-java400-l@midrange.com [mailto:owner-java400-l@midrange.com]On Behalf Of John Taylor Sent: Tuesday, March 06, 2001 7:04 PM To: JAVA400-L@midrange.com Subject: 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 +--- +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.