RE: Source Evaluation? -- JAVA400-L

Are all these available for people to use from your site? I looked at
it a while back but don't remeber seeing this. Sounds like you have
some good things going here.

Joe

-----Original Message-----
From: owner-java400-l@midrange.com
[mailto:owner-java400-l@midrange.com]On Behalf Of Joe Pluta
Sent: Saturday, February 10, 2001 12:15 AM
To: JAVA400-L@midrange.com
Subject: RE: Source Evaluation?


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

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