RE: beans and JSPs and stuff...

Nathan, my base model is built on the 5250-style communication model, where the 
bulk of the editing is done on the host.  It does not handle the event-driven 
model nearly as well.  My focus is on transforming existing business flows to a 
web interface.  Think of heads-down order entry or simple drill-through 
applications, where there is really limited client-side editing.

The widgets definitely do interact with client input, though.  Form fields are 
given names which correspond to the field names of the messages in their 
servers.  The HttpRequest object that contains the client input is then passed 
to the widget, which in turns extracts the data relevant to itself prior to 
processing any host updates.  This is the essence of my OO design: the widget 
both generates the form and extracts the information.

I think I addressed this a little in my earlier post:

[quote]
"There are two ways to go about this.  One is to expose the form and field 
names, the other is to generate the validation code.  I think it will depend on 
the manner of the validation. 

For the former, I don't see a problem with adding a form name parameter as an 
attribute for a form-type widget.  I assume this would be used as the id= 
attribute of the form tag.  In my architecture, which is designed to be used 
with messages defined on the host, field names are agreed upon between the host 
and the JSP.  They are the field names defined in the externally described data 
structure used to define the message.  Field names for table fields are 
prefixed by the row number. 

However, I believe that client-side validation should be limited to some very 
simple capabilities, primarily that of character validation.  Any edits which 
are much more involved than that, and you're starting to move your business 
logic into your client.  And that sort of validation [that is, the character 
validation] can be generated by the widget, thereby relieving the need of that 
sort of thing from the designer. 

And you'll of course have the same problem with CGI-generated HTML."
[/quote]

Here's the crux of the problem: Who defines the attributes of the input field 
on a form?  Are the definitions from the host, or in the JSP itself?  In my 
design, the definitions are all host-based, which allows green-screen 
programmers the capability of defining the messages.  All my JSPs eventually 
communicate with an RPG server program that contains all the business logic; it 
makes sense to me that the field definitions be under the control of that 
design team.  On the other hand, placement of those fields on the browser page 
should be the province of the web content team - that separation is what I try 
to provide with my component-based UI approach.

Joe


---------- Original Message ----------------------------------
From: "Nathan M. Andelin" <nathanma@haaga.com>
Reply-To: JAVA400-L@midrange.com
Date: Wed, 28 Feb 2001 10:33:34 -0700

>Joe,

Most JSP examples I've looked at contain a lot of server-side script, often
referencing input received from the client (HTML form variables, HTTP
environment variables, query string parameters, cookies, session data,
etc.).  It looks like your JSPs are much simpler.  Do your UI widgets need
to reference client input?  If so, how is that input passed?  And if not, I
assume you have other business objects that reference client input.  Do your
JSPs reference other business objects in addition to your UI widgets?  And
if so, do the business objects also need to reference the UI objects?  How
does it all fit together?

Nathan.

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