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

How does this differ from what Fred explained?  Are there pros, cons, or are
they the same?  When you say "subclass a class" I assume you mean to define
the one Formatter class, then for the XML and HTML classes, "extend" the
original formatter class.  

Brad

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
> Sent: Friday, March 16, 2001 5:10 PM
> To: JAVA400-L@midrange.com
> Subject: RE: HTML to XML, vice versa
> 
> 
> toML() in the FieldFormatter class looks like... nothing!
> 
> In fact, you can define it as an abstract method, thereby making
> FieldFormatter an abstract class.  The concept of an abstract 
> class is as a
> placeholder in the hierarchy that identifies the common 
> methods which are
> defined by lower classes.
> 
> If you don't want to go the abstract route, simply define it 
> like this:
> 
> public String toML() { return null; }
> 
> That's because, at the abstract level of the FieldFormatter, 
> the toML()
> method really makes no sense, and so should return nothing.  But by
> subclassing it, when you call formatter.toML(), the 
> appropriate toML() will
> be called based on the object stored in the variable "formatter".
> 
> This is the single, crucial point of OO design.
> 
> Joe
> 
> 
> > -----Original Message-----
> > From: owner-java400-l@midrange.com
> > [mailto:owner-java400-l@midrange.com]On Behalf Of Stone, Brad V (TC)
> > Sent: Friday, March 16, 2001 3:55 PM
> > To: 'JAVA400-L@midrange.com'
> > Subject: RE: HTML to XML, vice versa
> >
> >
> > Ok, I've got my XMLFieldFormatter class that extends 
> FieldFormatter.  The
> > code for it's toML() method is what was used to be in my 
> toXML() method in
> > FieldFormatter.
> >
> > Same for HTMLFieldFormatter, except HTML formatting.
> >
> > I have a method in my FieldDefinition class to set the 
> formatter.. It look
> > like this:
> >   protected FieldFormatter formatter = null;  (not sure if this
> > is correct)
> >   ...
> >   public void setFormatter(FieldFormatter fieldFormatter)
> >   {
> >     formatter = fieldFormatter;
> >   }
> >
> > The one thing I'm lost on is what does the toML() method 
> look like in the
> > FieldFormatter class?
> >
> > Also, when I say:
> >   field.setFormatter(new XMLFieldFormatter());
> >   outputString = (outputString + field.toML());
> >
> > I'm having a hard time understand _how_ this all works.  
> (I'm guessing the
> > code behind toML() in the FieldFormatter object may lend a clue).
> >
> > Brad
> >
> > > -----Original Message-----
> > > From: Joe Pluta [mailto:joepluta@plutabrothers.com]
> > > Sent: Thursday, March 15, 2001 2:56 PM
> > > To: JAVA400-L@midrange.com
> > > Subject: RE: HTML to XML, vice versa
> > >
> > >
> > > Of course, first recognize that what I'm presenting is my own
> > > view of how things should be done.  That caveat in place,
> > > you're getting closer, although there are a couple of
> > > differences between your approach and what I consider a true
> > > Decorator design.
> > >
> > > First, your static definition should not have anything
> > > specifically "HTML-ish" or "XML-ish".  It should have only
> > > things "Field-ish", such as field name.  If you have a
> > > "class" it should be a sort of generic class, that the
> > > formatter then turns into somthing specific to its format.
> > >
> > > Which leads me to the other issue.  You should not have a
> > > formatter with toXML and toHTML methods.  Instead, you should
> > > have a generic toString (or perhaps toML, as toString is a
> > > "magic" method name, but I use it a lot).
> > >
> > > Then, you have two subclasses of your FieldFormatter:
> > > XmlFieldFormatter and HtmlFieldFormatter.  The toML method of
> > > XmlFieldFormatter has the code from your toXML method, while
> > > the code for HtmlFieldFormatter has the code from the 
> toHTML method.
> > >
> > > Now, place a field in your field definition object called
> > > formatter, which is an object of type FieldFormatter.  Create
> > > a toML method like so:
> > >
> > >   public String toML()
> > >   {
> > >     return formatter.toML(this);
> > >   }
> > >
> > > Now, let's see what happens.  Whenever I want the ML for a
> > > field, I call its toML method:
> > >
> > >   String fieldML = field.toML();
> > >
> > > What will this return?  Well, it depends on what formatter
> > > I've assigned!  If I do the following:
> > >
> > >   field.setFormatter(new XmlFieldFormatter());
> > >   String fieldML = field.toML();
> > >
> > > I get XML code.  If I do this:
> > >
> > >   field.setFormatter(new HtmlFieldFormatter());
> > >   String fieldML = field.toML();
> > >
> > > I get HTML.  Now, you might say "How is that different than
> > > calling a different formatter, or a different method in the
> > > formatter?"  The point is that the field formatter object can
> > > be set at any time, and the code that uses the field will not
> > > change.  Most likely, you'll see something like this:
> > >
> > >   String outputString = field1.toML();
> > >   outputString += field2.toML();
> > >   outputString += field3.toML();
> > >   outputString += field4.toML();
> > >   outputString += field5.toML();
> > >   outputString += field6.toML();
> > >   outputString += field7.toML();
> > >
> > > If you've set the formatters to HtmlFieldFormatter, you'll
> > > get an HTML string, if you've set them to XmlFieldFormatter,
> > > you'll get an XML output.
> > >
> > > P.S. If you used the toString() method, you could do the
> > > following, which is why I do it sometimes:
> > >
> > > String outputString = field1 + field2 + field3 + (...) + field7;
> > >
> > > The toString() is called automatically when the compiler
> > > recognizes that it's doing a String function.
> > >
> > > Joe
> > >
> > > ---------- Original Message ----------------------------------
> > > From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
> > > Reply-To: JAVA400-L@midrange.com
> > > Date: Thu, 15 Mar 2001 08:53:54 -0600
> > >
> > > >Joe,
> > >
> > > This has made the most sense yet.
> > >
> > > So, here's what I have so far.  Let me know if I'm on the 
> right track:
> > >
> > > public class FieldDefinition extends java.lang.Object
> > > {
> > >   protected String name = null;
> > >   protected String xmlTag = null;
> > >   protected String htmlClass = null;
> > >
> > >   public FieldDefinition(String name)
> > >   {
> > >     this(name, "", "");
> > >   }
> > >
> > >   public FieldDefinition(String name, String xmlTag, 
> String htmlClass)
> > >   {
> > >     this.name = name;
> > >     this.xmlTag = xmlTag;
> > >     this.htmlClass = htmlClass;
> > >   }
> > > }
> > >
> > > public class FieldData extends java.lang.Object
> > > {
> > >   protected String data = null;
> > >
> > >   public FieldData(String data)
> > >   {
> > >     this.data = data;
> > >   }
> > >
> > > }
> > >
> > > public class FieldFormatter extends java.lang.Object
> > > {
> > >
> > >   public String toXML(FieldDefinition definition, FieldData data)
> > >   {
> > >     return ("<" + definition.xmlTag + ">" + data + "<" +
> > > definition.xmlTag +
> > > "/>");
> > >   }
> > >
> > >   public String toTD(FieldDefinition definition, FieldData data)
> > >   {
> > >
> > >     if (definition.htmlClass.equals(""))
> > >       return ("<td>" + data + "</td>");
> > >     else
> > >       return ("<td class=" + definition.htmlClass + ">" +
> > > data + "</td>");
> > >   }
> > >
> > > }
> > >
> > > To me, it seems I could combine the FieldDefinition and
> > > FieldData classes
> > > since I plan on having all the attributes dynamic.  Either
> > > that or I've put
> > > the wrong things in FieldDefinition.  Actually, just thinking
> > > about it that
> > > is what I should have done I'm sure.
> > >
> > > I just can't think of any examples of "static" field
> > > definitions to put in
> > > the FieldDefinition class.
> > >
> > > I dunno... whatcha think?  (anyone, as well as Joe.)
> > >
> > > Brad
> > >
> > > > -----Original Message-----
> > > > From: Joe Pluta [mailto:joepluta@plutabrothers.com]
> > > > Sent: Wednesday, March 14, 2001 9:09 AM
> > > > To: JAVA400-L@midrange.com
> > > > Subject: RE: HTML to XML, vice versa
> > > >
> > > >
> > > > Brad, in line with my previous post, you basically need
> > > three classes:
> > > >
> > > > FieldDefinition (which defines the static characteristics of
> > > > the field)
> > > >
> > > > FieldData (which holds the actual data object and any runtime
> > > > attribues)
> > > >
> > > > FieldFormatter (which takes a FieldDefinition and a FieldData
> > > > object, and returns the appropriate representation)
> > > >
> > > > You do NOT create a separate decorator for each field type;
> > > > you instead make your FieldDefinition very flexible and your
> > > > FieldFormatter very smart.
> > > >
> > > > Joe
> > > +---
> > > | 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
> > +---
> >
> 
> +---
> | 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
+---