× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: My Java Experience... latest code - critique
  • From: "Fred Kulack" <kulack@xxxxxxxxxx>
  • Date: Wed, 21 Mar 2001 10:22:52 -0600
  • Importance: Normal



This still implies to me that your abstraction for the
table concept isn't correct.

I don't really understand why the Table (FieldTableDefinition)
has to externalize so much field specific info.

Yeah, a table contains fields, but in this (and many other
usage models), the USER of the table doesn't need to know
or care about those fields. You're pushing functionality
OUT to the user instead of IN to the table
object where it belongs.

I recommend:
  FieldTableDefinition.setFormatter();
  FieldTableDefinition.toML();
After doing these two methods, you should suddenly see
a new interface that comes out of it.
I.e. the interface that has setFormatter() and toML()
should also probably apply to the entire table.
So that toML() on the table would probably call toML() on
all contained objects in 'appropriate' order for a table.


    FieldTableDefinition myTable = new
        FieldTableDefinition(databaseProperties, controlSQL);
    [... snip ...]
    for (int i = 0; i < myTable.size(); i++)
    {
      myTable.getFieldList(i).setFormatter(listFormatter);
      myTable.getFieldList(i).xmlWrapper="Data";
      out.println(myTable.getFieldList(i).toML());
    }

    could be replaced with:
    FieldTableDefinition myTable = new
        FieldTableDefinition(databaseProperties, controlSQL);
    myTable.setFormatter(listFormatter);
    // See my next comments about the 'xmlWrapper'
    out.println(myTable.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.

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.

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).



More nitpicky:
For HTML format, you're always creating two FieldFormatter objects.
First the default XML one, then the new HTML one. Object creation can
get really expensive in Java code. I'd recommend the XML formatter
instantiation getting put down the else leg.
    FieldListFormatter listFormatter = new XMLFieldListFormatter();
    [... snip ...]
    if (output.equals("HTML"))
    {
      response.setContentType("text/html");
      listFormatter = new HTMLFieldListFormatter();
      header = "table";

    } else {
      response.setContentType("text/xml");
    }



"The stuff we call "software" is not like anything that human society
  is used to thinking about. Software is something like a machine, and
  something like mathematics, and something like language, and
  something like thought, and art, and information...
  but software is not in fact any of those other things."
Bruce Sterling - The Hacker Crackdown

Fred A. Kulack  -  AS/400e  Java and Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack@us.ibm.com   Personal: mailto:kulack@bresnanlink.net
AOL Instant Messenger: Home:FKulack  Work:FKulackWrk

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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.