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