Carsten Ziegeler pisze: > Grzegorz Kossakowski wrote: >> Reinhard Poetz pisze: >> Hmmm, I have not considered flowscript when I was formulating my opinion on >> this subject and it was >> an obvious mistake. Your argument is of course valid and it seems that the >> best compromise between >> functionality, performance and separation is to provide access to the data >> from parent request but >> in read-only mode. It means we should allow sub-request to access request >> attributes of calling >> request. When it comes to session (even in read-only mode) I'm very >> circumspect. >> >> I believe that the best strategy is to allow as less as possible that still >> enable us to make full >> use of servlet service capabilities. >> >> WDYT? >> > I'm not sure - creating an artificial and somehow unusable session for > sub requests is imho no solution. It somehow doesn't neither make sense > nor does it feel right. > > In the portal world, the session is shared between portlets and servlets > residing in the same web application - there is no difference in terms > of usability between a portlet or a servlet. The portlet spec does not > want to impose restrictions, however it gives guidance to not mess up > with the session and missuse it. > > For some applications, the session contains required information like > the local or some preferences. You definitly don't want to pass them do > sub requests by getting them from the session and putting them into the > request.
It may sound controversial but I think that things like information about user locale or preferences should be kept in URL (preferably in path part or in request parameters). If data set is too big, URL should contain an unique identifier of this data set. I mean, instead of using following URL: /blog/posts/1 and passing following information: Locale=pl-PL, Username=gkossakowski, Skin=red it's better to have following URL: /blog/languages/pl-PL/skins/red/posts/1 Or, if username is needed for other reasons (like we need to access other preferences): /blog/profiles/gkossakowski/languages/pl-PL/skins/red/posts/1 Then profile name 'gkossakowski' becomes a lens that we use to have a view on post 1, stylized using red skin and showing controls in Polish language. Lens named 'gkossakowski' can provide additional settings impacting on how the page looks like. For example, simple "Hello Grzegorz" can be provided at the bottom of page. As you see, URL includes userid that can be used to fetch preferences from database (or webservice, if we are playing with remote profiles, for example) and use them as a lens. It brings us straightly to the conclusion that each resource has zillions of different (but unique and persistent!) URLs depending on who looks at it. Such design results in prons and cons of course. Obvious advantage of having unique URLs for each view of particular resource is that you can paste it while having a chat with pal and you can be absolutely sure he will see exactly the same page as you see including "Hello Grzegorz" greeting. The disadvantage is such a weird behaviour that John accesses the page and is welcomed as Grzegorz. Simple solution to this problem is to carry information who looks through whose lens. In our case, simple cookie with information about real userid could be passed affecting a little a dispayed page with information: "You are looking at this page using Grzegorz settings, if you want yours go here." Or even you can configure to redirect automatically in such case. It really depends on particular application needs. Ok, you may think it's academic speaking (yes, I'm a student spending most of my time at very high levels of abstraction) but I really believe it may work and scale very, very well. It goes in harmony with REST principles, and... there is no session needed. All user preferences all in persisted all the time. Getting back to the topic, I tried above to proof that having a session is not essential part of web application creation process. > We are relying/basing on the servlet specification and it seems somehow > wrong to me to explicitly disallow some things just because some of us > think that this is evil - it doesn't matter if this is evil or not, it's > the servlet spec in the end. And this spec states that the session is > shared by all servlets etc. So I think we should give full access to the > session but explicitly document the problems. If people want to mess up > with it, well, that's their problem - if people know what they are doing > and need (write) access to the session, they have it. Whenever I think about Servlet Services Framework design first spec I have in mind is HTTP (+ publications about REST that made me think about HTTP in more appropriate way). Always and ever. The fact that we follow servlet specification as much as we can instead of reinventing the wheel is good of course. Nevertheless, I keep HTTP and REST over servlet spec. I think it's worth to remind KISS rule as it fits very well in this case. If we let a session to be shared at this point there will be probably no way back. Apart from SSF being a really nice idea, I like to work on it becuase, in contrary to cocoon protocol, it allows much less thus code is simpler, cleaner. Also, it makes me to think more about a proper design of my applications that will fit into narrowed functionality. The overall result is always a better SoC, better design and cleaner contracts. I think that limitations (but well thought through!) are our friends not evils. WDYT? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
