abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject CollectionProvider improvements
Date Mon, 29 Oct 2007 02:21:43 GMT
I've been working with the CollectionProvider stuff a bit more, but I've 
run into a couple limitations. I don't think they're insurmountable, but 
I wanted to hear what people though about the possible solutions.

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.

2. Sessions/Transactions. I was toying with a JCR collection 
implementation. JCR requires that we start a session at the beginning of 
the request and logout of the session at the end. You also need to have 
access to the Session inside your CollectionProvider implementation.

I can think of a few possible solutions to these things, but they're all 
kind of ugly IMO.

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.

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

public ResponseContext getEntry(RequestContext cxt) {
CollectionProvider cp = workspace.createCollectionProvider(...);
// make the context available via CollectionProvider.getRequestContext()

// do custom session creation logic

Entry entry = ...;
Object entryObj = cp.getEntry(resourceName);
entry.setTitle(cp.getTitle(entryObj ));
... etc.

// do custom session logout logic

Creating a new CP seems slightly annoying to me, but this seems to be 
the cleanest solution.

3. Add a RequestContext variable to most/all of the CollectionProvider 

public abstract Iterable<T> getEntries(RequestContext ctx) throws 
public abstract <T> T getEntryFromId(String id, RequestContext ctx) 
throws ResponseContextException

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.


I get this feeling though that I'm missing some better paradigm. Any one 
have better ideas? (or did this make any sense at all?)

- Dan

Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

View raw message