RE: My Java Experience... latest code - critique (xmlWrapper)

referring to this code:

      myTable.getFieldList(i).setFormatter(listFormatter);
      myTable.getFieldList(i).xmlWrapper="Data";
      out.println(myTable.getFieldList(i).toML());

> 
> This xmlWrapper thing looks pretty evil too,
> and implies to me you need to scramble things
> a bit more here.
> 
> How about a more generic XMLFormatter model?
> Your XMLFieldFormatter is very dependant on a Field,
> where it probably doesn't need to be.
> Also, you're sticking XML information in the field.
> That doesn't seem to make a lot of OO sense.

The xmlWrapper applies to the row of data (fieldList), not the data itself
(the field).

Each field already had an XML tag attribute.  This is so you have:
<field1>data1</field1>
<field2>data2</field2>

But, when I'm outputting the table, I need to wrap the set of fields in a
tag as well.  Like this:
<fieldwrapper>
  <field1>data1</field1>
  <field2>data2</field2>
</fieldwrapper>

The "fieldwrapper" is my xmlWrapper attribute.  It is an attribute of
FieldList, not field.

here's the structure... Field, FieldList (a vector of Field), FieldTable (a
vector of FieldList).  PErhaps the flaws in my design go back to the most
elementary of these.  Should FieldTable rely on the fact that it will
contain only Field types?  And should FieldTable rely on the fact that it
will contain FieldList objects?

I'm sort of lost as to how else I can get that piece of data (the row
wrapper) into the FieldList object.  

> 
> Perhaps something like this (perhaps not).
> 
> The xmlWrapper attribute on your field should
> be a METHOD. And it should be non XML related
> At an OO level, there's really nothing in a field
> that has anything to do with XML.
> 

This is the part of OO that really confuses me.  :)  I understand it should
be as abstract as possible, but as some point you have to call your "animal"
a "monkey".  To me this type of thing just delays the inevitable to the last
minute, in the meantime causing you to create more abstract objects.  I know
I'm missing something, and it will come in time, but I just want to express
my thoughts now as I'm sure others have the same feelings.  It also helps
the OO folks to understand where my head is.  :)  

> I.e. Perhaps setName()/getName(), where the
> XMLFormatter uses the NAME from a 'Nameable'
> object instead of the xmlWrapper attribute
> from a 'Field' object.
> 
> Suddenly, Field and XMLWrapper become more independant
> of each other by using a new 'Nameable' interface
> that looks something like this:
> 
>  public interface Nameable {
>    public void setName(String name);
>    public String getName();
>  }
> 
> 
> NOW, explore making other things in your implementation
> (like the TABLE) implement Nameable. Suddenly, you've
> got a model where you might be able to have a single
> XMLFormatter that can XML format multiple object
> types (i.e. it formats Nameable objects).
> 
> 
I understand this, but again, what's the difference?  Now all of my objects
rely on the Namable object as well.  My field has many different attributes.
My fieldlist has fewer and my fieldTable has the same as fieldList.  So if I
go the Nameable route, then wouldn't I make an interface for each attribute
of my field?

ie:
Nameable() (to hold the name of the piece of data)
Data() (to hold the "data" in this piece of data)
Classable() (to hold a class for this piece of data, for instance if it is
an HTML table cell and I need a class for it)

Whew!  the scary thing is, when I just typed the above I realized that the
Classable() was probably something that is "to HTML specific" for my object,
but then my head goes back to thinking "well how do I get this then?"

My heads going in circles right now.  :)

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