I agree, we have been searching for ways to do this elegantly for some
time.
The way I have specified it wouldn't make this happen, but it would
allow it to happen without the extreeme kludge which many people have
complained about.
Since the ParameterStore (for want of a better name) object would be
an object abstracted from a Hashtable and with few methods of its own
it would be much easier to extend it to deliver correct ordering.
The ordering that you cannot gaurantee is the ordering coming back
from the broswer. The Http protocol specifies that there is no
particular ordering.
But it would be possible to apply predictable ordering, ie: sorted.
Nic
>>> Formanek Gary L <[EMAIL PROTECTED]> 3/25/99 1:36:00
PM >>>
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
___________________________________________________________________________
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
