>Here's a thought... It seems to me that processRequest is most often used
>as an indication for the bean to "do its work". In other words, the bean
>expects a bunch of set* calls, a processRequest call (where the work is
>done), and then a bunch of get* calls.
As a user of processRequest(), I can see a couple of issues. First of all,
it adds a fair bit of overhead. Second, and perhaps most important, it
doesn't provide the bean with any hooks into the request object. If you're
using a Model 1 approach, it's very common for your beans to need to hook
into the underlying servlet data structures, and in 0.92 processRequest()
was the only mechanism for doing so, outside of scriptlets.
This is not to say that they're aren't problems with processRequest(). In
particular, when a JSP page has multiple <USEBEAN> tags, it would be nice
to control whether or not a given bean's processRequest() method is called
(if it exists). I liked a recent suggestion (I wish I could remember who
made it) of using a base class for data beans with processRequest() methods
implemented in subclasses. Alternatively, perhaps yet another attribute
could be added to the <USEBEAN> tag indicating whether or not to call
processRequest(), or perhaps even to specify the method to call.
With respect to those who feel processRequest() marks a bean as
non-standard, I have to point out that the AWT components that have been
elevated to bean status also bring along a fair bit of non-bean baggage
methods such as paint(), update(), etc.
Of course, the tag extension and/or event handler mechanisms in 1.1 may
make this all moot...
- Mark
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
