I haven't looked at Collections yet, but I'm assuming this would allow us to
get the form name/value pairs in the order they exist on the page if this
framework existed. That has been one of the things I would like to see. I
know there have been several ideas of how to do this, but they're kludgy.
While a Hashtable is nice for many things, it doesn't help with this. There
are times when you just want to send an email with the form information to
someone and keep it ordered like the form was.
Thanks,
Gary
> -----Original Message-----
> From: Nic Ferrier [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, March 24, 1999 4:31 PM
> To: [EMAIL PROTECTED]
> Subject: Hashtables and Servlets
>
> I've been thinking about this.
>
> I'm sure James and the team have noticed how many of us are writing
> frameworks and I'm sure the guys have also seen the postings on this
> list.
>
> Both of these phenomena are related to the fact that the Servlet API
> uses an abstract implementation of a hashtable (in the generic CS
> sense) but that object is tied deep within the Request object.
>
> It's just a suggestion but what would people (James and the team
> included) think to abstracting the parameters out of the request
> object?
>
> We would then need an object that looked very much like a hashtable,
> as an example let's call it ParameterStore.
>
> ParameterStore would include the methods:
>
> String getValue(String Name);
>
> String[] getValues(String Name);
>
> Enumeration names();
>
> We talked some time ago about the possibility of extending the
> Servlet API to Java 2 (which would obviously break compatibility).
>
> ParameterStore could implement Collection but it could simply extend
> Hashtable or Dictionary or it could simply stand on it's own.
>
> The existing parameter methods could remain but be deprecated since
> it would be possible for servlet engine writers to use an internal
> ParameterStore to deliver the parameter information through the
> Request methods.
>
> This would add Object load to the API and I understand the desire to
> keep things light but it would also improve the abstraction. At the
> moment an object which represents a request has to be really mangled
> to fit into good Object design programs. This would reduce that need.
>
> Of course the name need not be ParameterStore, it could be anything.
> Also it could simply be a Hashtable or some sort of Map.
>
> I suspect that those are out of favour though because the user should
> not be able to delete parameters from the request (which of course you
> could do if you used Hashtable).
>
> Anybody agree?
>
>
>
>
> Nic Ferrier
> Tapsell-Ferrier Ltd
> www.tapsellferrier.co.uk
>
> __________________________________________________________________________
> _
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
