Reinhard Poetz skrev:
> Ralph Goers wrote:
>> Daniel Fagerstrom wrote:
>>> Letting all blocks share the same global session would lead to code
>>> that would be hard to debug and reuse, so that would not be such a
>>> good idea. We could think about having a local session for each
>>> servlet service, but that is not implemented yet.
>>>
>>> What you currently do is that you have a "main" servlet service that
>>> contain session handling etc and that calls other servlet services
>>> that does there work without sessions. For me that is enough, but if
>>> other people have use cases that require more, we can find some way
>>> to extend it.
>>>
>>> /Daniel
>> Thanks for this info. This does raise concern although perhaps it is
>> misplaced. I am working on a project that heavily uses portlets. The
>> current portlet spec makes it difficult to share session attributes
>> across the web application. The downside is that it leads to all
>> kinds of kludges and performance problems. For example, you would
>> like to call a single business service and have its data available to
>> multiple portlets as each might simply provide different views of the
>> data. I could easily see the same sort of requirement with blocks.
>>
>> In general, the isolation is probably the correct approach, but only
>> if there is a way to explicitly declare that certain objects should
>> be shared.
>
> I'm not sure if it is directly helpful for your problem, but Spring
> 2.x offers request, session and global-session scoped beans
> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).
>
>
That is one possibility. And as the Spring container is global another
possibility is to let your multiple "view blocks" access the Spring bean
directly.
A third possibility would be to make your "data" available as REST-style
web services. Then the "view blocks" can access the data through servlet
service protocol calls.
Then we could of course create some mechanism such that each servlet
service has a local session that in some way extends and overrides the
global one. Maybe using some special syntax for global session attribute
names.
/Daniel
|