> From: cristi [mailto:[EMAIL PROTECTED]
> The requirement of making a copy of the HttpServletRequest is
> generated by the fact that the former programmers have used (in a
> natural manner):
>
> 1) the HttpServletRequest.setAttributes() to send data to the jsp
> pages creating the response. ( These data is the servlet
> computation result).
>
> 2) within the jsp pages creating the result various methods of the
> HttpServletRequest (other than
> HttpServletRequest.getAttributes() )
> object are used to get information from the request object.
OK. I agree, that's natural - if not a good design for future
requirements change.
> Now there is the requirement that in the second request sent to the
> servlet we have to use the computation result of the first request
> (that is those data that you could find using the
> HttpServletRequest.getAttributes() applied to the request object sent
> in the first request ) to create the final HTML page.
OK. So there's been a requirement change for which the original
approach was not designed, and so somebody on the business side (an
internal or external client) has to find the effort and the budget to
make that change, or decide that the change is too expensive and not
make it. Somebody on the technical side has to inform them of the
expected effort, and keep them informed if that changes.
> Let's supose now that in the second request we have a way of finding
> the computation result of the first request. This is not enough to
> satisfy the second request because in order to render the HTML page of
> the second request we also need other information which can be found
> in the request object sent during the first request
> (e.g. HttpServletRequest.getParameter() );
>
> I hope that I was explicit enough.
You have been - many thanks.
> We knew it from the start that a solution exists (saving
> and using all the data that we need between the requests
> but this is not an easy task now since we have to
> analyze - and to write - a lot of code), but since all
> this data can be found in the request object sent to the
> servlet with the first request we thought that making a
> copy of the request object should be very easy
A suggestion for future projects: never presuppose that an external
piece of software will make your life easy. Sounds cynical, I know.
> (and very natural at the same time).
Um. Yes, until someone makes another change in the original pages that
breaks your code to pull out the data. The approach is fast to code,
but fragile in the face of changes.
I suspect that, if you still want to follow this approach, about the
best you can do will be to create an alternative request implementation
that stores the fields you need, plus code to copy them out of the
original request into your alternative implementation. Your alternative
only needs to store the minimum of data that you need for your
application - of course, this is fragile if further changes are made and
you realise more data should have been stored, and your developer
assumes that your partially-implemented class is actually complete. You
can then store that alternative object; as you have implemented it, you
will know about its lifecycle.
If you do this, I think you're making your application more and more
fragile. Instead of this, I would take the time at least to write a few
functions to retrieve your data - you could choose to simply pass a
parameter to decide which data source to use, or you could use (say) an
Adapter pattern to write an interface to the data, one implementation
that takes that from the current request, and one implementation that
takes it from your preserved data store. You've then insulated yourself
from further changes. It may be up to the development team to decide
how much insulation they want; I'll just note that most applications
change more, and more frequently, than the developers expect.
- Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
