|
midrange.com
What you have done sounds really cool and there are many of us out there
from RPG-Land trying to figure out how to make all this work. Why don't you
write some of your work so that we can gain some insight? I bet Midrange
Computing or AS/400 Iseries Network (News/400) would publish it.
Thanks!
Don Burdette
"Joe Pluta"
<joepluta@plutabro To: <JAVA400-L@midrange.com>
thers.com> cc:
Sent by: Subject: RE: beans and JSPs
and stuff...
owner-java400-l@mi
drange.com
02/28/2001 10:08
AM
Please respond to
JAVA400-L
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
+---
+---
| 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
+---
+---
| 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 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.
