RE: beans and JSPs and stuff...

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

Stylesheets, XML, whatever you want to use to change the look and feel.
Nothing returns "pure data" in the sense you are talking about.
--------
Actually, in my design the DataTable returns pure data.  Not until the data is 
decorated by the DataTableWidget does it take on any formatting.  This is the 
basis of O-O design.  The DataTableWidget uses a pluggable formatting object to 
determine the formatting, be it HTML, WML or whatever.


>JSP doesn't magically make coding go away.  The coding has to be done
>somewhere.  It's not a lot of coding.  

JSP makes code go away for the person designing the presentation layer.  And to 
do it right, it IS a lot of coding.  My widgets are completely self-contained 
and provide capabilities such as dropdown lists tied to data files, error 
formatting, valid value lists and so on.



>I assign classes (for the 100th time).

No, not for the 100th time Brad.  This is the first time you've explained it.  
Because otherwise I would have made the following observations a little earlier:


>mycgipgm reads data, any env. vars it needs to decide what styles to >apply,
>and reads a database and outputs a table.  Same as your widget, or the >code
>behind it.

>Stylesheet defines font, color, style, etc of the classes.  Pretty >simple
>actually.  If you want to change styles between pages, you can set the
>stylesheet location accordingly.
-------
How do I assign different colors to, say, different columns in a table?  

Or, let's say I want four different tables, each with it's own background 
color, each containing different fields from a record.  How do I do that?  Who 
assigns the four different classes?  I need four different programs, each with 
its own hardcoded class names.

Okay, let's say we've agreed on the four different classes. What happens when I 
want to split one of those tables into two?  Where do I define the fifth class 
(or set of classes, in the case of a table)?

In a component widget architecture, I simply define a new widget with different 
fields, and assign a style, which could even be an inline style:

<%
  String[] fields = new String[] { "field1", "field2", "field2" };
  String[][] style = new String[][] { { "bgcolor", "green" } };
  widget = new FieldSetWidget(record, fields, style);
%>

<%= widget %>


In CGI, I have to do the following:

1. Remove the fields from CGI program Widget4.
2. Create a brand new CGI program Widget5 with the new fields.
3. Agree on a class ID for Widget5 that doesn't conflict with the other widgets 
(or any other widgets).
4. Add the new class to my style sheet.
5. Position the SSI include on my HTML (this is the same as positioning it in 
the JSP)


And I have to do this every time I want to move some fields around on my screen.

This is wildly counterproductive.



>CGI is CGI is CGI.  Somewhere down the line you have to have something
>outputting dynamic HTML.  Because it's hidden in a widget does not mean it
>isn't there.  And as you can see from our examples, we simply have a spot in
>our HTML that is "replaced" by dynamically generated HTML.  It's all the
>same in the end.
-------
No, and that's where you and I fundamentally disagree.  You insist that you as 
a programmer can design a good UI.  I know for a fact that I cannot.  My job is 
to make data available to the UI designer in such a way that he can build a 
good presentation.  It's my job as a component widget designer to allow the 
maximum flexibility in the finished output, completely controlled by the end 
user.  Styles work to some degree, but they're awkward for some things, such as 
cell borders, spacing and padding.  And if you have multiple components on a 
page (say, four tables), you need a good mechanism for attaching individual 
styles to the individual tables.  You'll need to somehow assign a prefix or 
something to the CGI when you call it.

It's certainly doable.  Just takes a bit more work.  And that's where 
object-oriented code comes into play.  By subclassing my various widgets from 
common abstract classes, it becomes very easy to add formatting capabilities 
that instantly are available throughout all of my widgets.


There's also one other capability component widgets have.  They can include 
backend processing.  Each widget class is also capable of receiving data 
directly from an HttpRequest and then communicating with a host program to 
update the appropriate persistent data.  That backend processing has to be done 
in a servlet program in your scenario.  Which means that the servlet has to 
know which widgets are coming in.

With an object-oriented design, pretty much any servlet can process any widget, 
because it's sole purpose is to pass the HttpRequest (containing the user 
input) to the widget and then invoking the widget's update methods.  The only 
decision then is whether to redisplay the current JSP (if there's an error) or 
go on to the "next" JSP.
+---
| 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
+---