RE: Source Evaluation?

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

Actually, I've already got that, Joe.  I've got an AbstractWidget class and
an AbstractTableWidget.  Subclassing these are various types
(DataTableWidget, QueryDataWidget, PromptWidget, and so on) which all use
the toString() method to return a UI data stream.

The AbstractWidget also supports a variety of utility methods for debugging
and viewing, as well as providing hooks for loading data from an HTTP POST
(for bidirectional communications with the model).

Next, I've got an AbstractFormatter which is used by the widgets to actually
build the appropriate stream.  I've got an HTMLFormatter which subclasses
AsbtractFormatter to supply HTML-specific tags.  I can then create
WMLFormatter or XMLFormatter or (if I felt really crazy) X5250Formatter
which could return a 5250 data stream.

However, the data returned by the HTMLFormatter is pretty hardcoded.  What I
want is the ability to dynamically change the format of the output.  And
this is where the HTMLStyle object will come into play.  By attaching an
HTMLStyle object to a widget, I can control its output.  For instance, the
AbstractTableWidget will allow me to attach an HTMLStyle to the table header
and to the table cells, as well as one to the overall table itself.  The
FormattedFieldWidget will have different styles for input-capable,
input-capable with error, output-only and output-only with error.  In each
case, the HTMLStyle object will be used during the formatting phase to
create an inline style string.

This will allow ultimate flexibility for the UI designer, and will afford a
very high degree of separation of presentation and business logic.  However,
whenever I've added such flexibility to my designs, I've made it a rule to
allow two things: a reasonable set of defaults, and a way to define those
defaults in an .ini file (or .properties file, as the case may be).  This
way, a beginner can toss something together with no particular worry about
the end result, yet still get something worthwhile.  At the same time, a
designer can create a set of corporate standards and store them in the
.properties file to be used as the base for all applications.

And it's this final piece of the design that I'm trying to address when I
create the Categories object fed from the .properties file.  I've already
got the style stuff in place - and you haven't lived until you've seen a
table with yellow Arial bold letters on a green background with a 5-pixel
red border <grin>.  Now I just have to put the defaults in place.

Joe


> -----Original Message-----
> From: owner-java400-l@midrange.com
> [mailto:owner-java400-l@midrange.com]On Behalf Of Joe Teff
> Sent: Friday, February 09, 2001 8:43 PM
> To: JAVA400-L@midrange.com
> Subject: RE: Source Evaluation?
>
>
> You could mimic the Java AWT/Swing model. Define a widget
> class that is the parent of all HTML output types. Then
> create classes to generate each specific type of output
> text, input fields, tables, etc.).
>
> A table (for instance HTMLTableWidget is just another
> class with methods to add rows, set headers, set
> properties. The toString() method would generate a
> String with all of the appropraite tags along with the
> data.
>
> 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
+---