abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: CollectionProvider improvements
Date Mon, 29 Oct 2007 04:00:03 GMT
I don't have any strong opinions about this other than really wanting to
make sure things stay fairly simple.  With that said, comments below.

Dan Diephouse wrote:
> [snip]
> The problems that I've run into are main along two lines:
> 1. A developer will need access to information which isn't explicitly
> part of the AbstractCollectionProvider methods. For instance, lets say
> someone is GETing a collection, but they've specified some open search
> query parameters. These are not passed into the
> AbstractCollectionProvider.getEntries method. Which leaves them up a creek.
> 

EWww.. that's bad.  This is precisely why the RequestContext object
exists.  We need to make sure the context is always available.

> [snip]
> 1. Supply the RequestContext to the user via a ThreadLocal variable. Or
> in the case of #2, supply the Session via a ThreadLocal variable and
> provide hooks inside the Provider to do things at the beginning/end of
> the request. This is probably my least favorite option.
> 

-1. Not a good option.

> 2. Change the scope of CollectionProviders from singleton to request
> scope and set properties on the CollectionProvider. In essence each
> request would do something like this
> 

This would be fine so long as we have the option of pooling the
CollectionProviders.  Instances of the provider should not maintain
request state.

> public ResponseContext getEntry(RequestContext cxt) {
> CollectionProvider cp = workspace.createCollectionProvider(...);

An ItemManager instance could be used here to enable pooling.

> // make the context available via CollectionProvider.getRequestContext()
> cp.setRequestContext(context);

-1. I'd rather see something like cp.getEntry(context)

> [snip]
> 3. Add a RequestContext variable to most/all of the CollectionProvider
> methods:
> 
> public abstract Iterable<T> getEntries(RequestContext ctx) throws
> ResponseContextException;
> public abstract <T> T getEntryFromId(String id, RequestContext ctx)
> throws ResponseContextException
> 

+1

> For the session/tx use case, the Session can be set inside the
> RequestContext and pulled out via ctx.getAttribute().  The thing I don't
> like about this option is that it adds clutter.
> 

- James

Mime
View raw message