Oops! That makes sense though. Dropping the reference to IPortletEntity within IPortletCookie would clear up some of the troubles I ran into recently.
On Tue, Jan 18, 2011 at 9:01 AM, Eric Dalquist <[email protected]> wrote: > That would actually be option 1. If we did option 3 the reference from the > IPortletCookie to IPortletEntity would go away and all portlets would see > all cookies for a particular browser. > > -Eric > > On 1/18/11 8:30 AM, Nicholas Blair wrote: >> >> I've been working from option 3. >> There are 2 key elements in the data model: >> >> IPortalCookie, which represents a single Cookie Eric is referring to >> (1 key to relate to all portlet cookies). >> IPortletCookie, which mimics javax.servlet.http.Cookie per the portlet >> spec, but also provides a reference to the IPortletEntity that spawned >> the cookie. >> >> There isn't any scoping - as far as I've gotten - so any portlet can >> see all Cookies (IPortletCookies) in the request. >> >> When a portlet calls: >> >> javax.servlet.http.Cookie[] PortletRequest#getCookies() >> >> Should the returned array contain all non-portlet cookies as well? The >> only mention in the spec is: >> >> 11.1.5.1 >> The portlet can access cookies provided by the current request with >> the getCookies >> method. The returned cookie array provides the portlet with all cookie >> properties. >> >> I read that as yes, all Cookies returned by the normal ServletRequest >> should be included. >> >> On Mon, Jan 17, 2011 at 9:28 PM, Eric Dalquist >> <[email protected]> wrote: >>> >>> Hrm, that is a good point. The spec does refer to them in the same areas >>> where it refers to using portlet request/response properties as HTTP >>> headers >>> which also implies no scoping. 3 would also be the easiest to implement >>> since then the cookies have no relation to the portlet definition or >>> entity >>> objects. The more I think about it the more option 3 really seems to make >>> sense. >>> >>> Our general plan for implementation is that uPortal will always set a >>> specially named portal cookie with a big-random-token value in the users >>> browser and store that token in the DB. Any time a portlet sets/reads a >>> cookie it will actually be stored in the DB and never actually sent to >>> the >>> browser. The big technical reason for this is since uPortal is what the >>> spec >>> calls a Streaming Portal by the time portlets have started rendering >>> there >>> has already been content written to the browser. We'll have a background >>> task that does purging of the portal cookie and portlet cookies from the >>> DB >>> to make sure these cookie stores don't just grow forever. >>> >>> -Eric >>> >>> On 1/17/11 4:40 PM, Steve Swinsburg wrote: >>> >>> You're right, it is confusing. From what I have read, there is no >>> guarantee >>> the cookies from one portlet will be available to another one (which is >>> either 1 or 2 below) but it seems an odd use of cookies and general >>> knowledge around the use of cookies would probably assume 3. >>> regards, >>> Steve >>> >>> >>> On 18/01/2011, at 3:30 AM, Eric Dalquist wrote: >>> >>> Nick Blair is working on the cookie support for portlet 2.0 and we've >>> come >>> to a bit of confusion. After re-reading the portlet spec on cookies >>> several >>> times now and one thing is still not clear, how are cookies set by >>> portlets >>> scoped? >>> >>> It seems like there are a few options: >>> >>> Cookies are scoped the same way Preferences are, to the instance of the >>> portlet entity >>> Cookies are scoped at the definition level, essentially Portlet A can >>> share >>> a cookie among any number of users but Portlet B will never see it >>> Cookies are not scoped at all. All portlets work in the same general >>> space >>> for cookies and a cookie set by Portlet A can be seen by Portlet B >>> >>> Does anyone here have thoughts on the intent in the spec or just what >>> your >>> gut feeling would be? >>> >>> -Eric >>> >>> -- >>> >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
