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

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