RE: beans and JSPs and stuff...

> I see a lot of client-side Java Script included in web pages these days.
> The script frequently references HTML components by name (i.e.
> document.form.field.value).  Browser script may validate or even
> change HTML
> component properties at runtime.  Do your widgets return HTML components
> with names that are known to the JSP author at design time?  How can a
> script author reference widget generated HTML?

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
whcih are much more involved than that, and you're starting to move your
business logic into your client.  And that sort of 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.


> I see a lot of parallels between class instantiation and DLL
> loading.  When
> a JSP references a large number of widgets, how do you prevent
> load overhead
> for each widget instantiated?

"Load overhead"?  Since we're talking Internet and human interface, the
actual build time for even 100 widgets is far less than the transmission
time, and certainly less than operator think time.  If you truly find
performance issues, you can do quite a few things with lazy constructors and
preloading, but in practice I'm seeing subsecond response time.


> It looks like the primary purpose of widgets is to dynamically generate
> client code (HTML, etc.).  Are they not, in effect mini-CGI components in
> and of themselves?

Only in their end product, a string of formatted HTML.  But the
architecture - pure data wrapped in a UI widget decorated by an ML
formatter - is really only practical in an OO language.  That's not to say
you can't do it in a non-OO language; I did something similar in C in the
early 90's.

Also, I can test these widgets in a non-servlet environment, which is really
cool.  And finally, CGI is output-only - my widgets also support the update
of data using the data input on the form, with pretty much no code in the
servlet.

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