I'm not on expert on Cookie, but what I learned while writing the persistence code. - The path is used by the browser to select which Cookie to added to the request header and thus is required as well - security, etc. are only useful for https (secured) connections. As long as we only store data locally and not using http, removing it would probably fine. But can we sure that this is the case?
I remember I thought about replacing the Cookie class as well, but finally I decided not to because: a) Cookies are the primary means to store form component data b) If class Cookie is the reference and I want to store the data in a database instead of the browser, it'd still be very easy. FormComponentPersister is already pluggable and every user might replace it. Either with a simple one just storing key/value, or all data available. c) I know not above about Cookies and how they are used in real life application to decide whether some of its variable are needed or not Hmm, while thinking about it, the arguments are not very strong, except security enabled. Juergen On Tue, 25 Jan 2005 11:45:36 -0800, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > i mentioned last week i'd be going in to rework the cookie persistence > stuff a little. > now that i've taken a little longer to review the code, i think it is > actually useful, but > needs more abstraction from "cookie nature". as i'm doing this, i'd > like to preserve > as much of the original capabilities as possible. has anyone out there > written code > that makes use of something about a Cookie other than its name and > value? if so, > what did you use and why? my thought is that form components really > just persist > string values in the end and so i'd like to remove all the Cookie > references as well. > the advantage here is the original intent (now that i remember it!), > which is to give > users an easy option for implementing form component value persistence > without > using cookies. this idea was a security thing and seems useful still, > but i think the > Cookie details should be hidden since the only purpose of a cookie is to > provide > a value for a String. at a later date, we will be able to easily > implement a form > component persistence manager which persists to a database (which won't, and > shouldn't, have any of the Cookie details). > > any comments? > > thanks, > > jon > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
