If support was to be added to ParameterParser I think we could create some
confusion with regard to the order of Cookies/Path_info/Post data. Another
problem is that cookies require some extra parameters (e.g. expiry time)
that are not relevant to Path_Info/Post data.
How about data.getCookies() that returns a CookieParser object.
CookieParser and ParameterParser should inherit from the same base class and
extra functionality as needed (e.g. expiry time for cookies). By inheriting
from the same base class it will be possible to use features like
setProperties() for both ParameterParser and CookieParser, while still
allowing extra features to be added.
Any thoughts?
~ Leon
> If support for cookies is to be built into turbine. I think the most
> logical place to put it would be ParameterParser (PP) as it is just
> request data. Already PP provides a central location to grab data from
> GET/POST/PATH_INFO. It is a reasonable location for storing Cookie
> parameters as well. One potential problem is that right now PATH_INFO
> will overwrite GET/POST data. I think GET/POST precendence is set by
> the servlet spec, but I could be wrong. The order here may not be as
> important as each of these types of data are generated per request, a
> cookie however could be interpreted as a default that should or should
> not be overridden by other request data. And the should or should not
> question might be answered differently in different applications.
>
> I think it is possible for an application to need persistent data
> relevant for a specific user and not have it be so sensitive that it
> requires explicit user knowledge and a login step. A tv guide app for
> example could only request a zip code to set up a user account, the user
> then might alter their preferences as far as channels, etc. This
> provides the tv guide company with the ability to profile each
> user's/family's tv viewing preferences and it is completely anonymous.
> People tend to use the same username/passwords over and over. If an
> application has little need to require a user to supply a u/p then don't
> ask for one.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
