Dan Diephouse wrote:
I've commented on a couple things which I have other thoughts on, but
overall it looks good.
James M Snell wrote:
The default provider implementation will extend
AbstractWorkspaceManagerProvider.java. This class implements boththe
Provider and WorkspaceManager interfaces.
I would also like to float the idea that the Provider should take a
WorkspaceManager as a property/constructor. This way I as a user just
implement WorkspaceManager which can look up collections from my
database and pass it in as an argument to some stock Provider.
The WorkspaceManager is equivalent to the current WorkspaceInfo
interface. It's primary function is to lookup the appropriate
CollectionAdapter instance.
We still need a way to describe the workspaces though. A la
WorkspaceInfo.getName/getCollectionProviders. Are you sure we don't need
WorkspaceInfo still?
WorkspaceInfo is still going to be there, it will be used for
Provider/Adapter implentations that derived from what is currently your
CollectionProvider code, which I am currently in the process of
porting/adapting over the revised model. Once I finish porting and you
get a chance to review, I think it will make sense.
A CollectionAdapter instance can choose to implement the Provider
interface in order to support extension methods.
I'm not sure that provider is the right interface to do this as it mixes
semantics a little bit. My alternative proposals would be to either:
1. have a fallback method built into CA like doOther(RequestContext) or
something like that.
2. Make the Provider responsible for choosing a method via some sort of
extensible dispatching mechanism
Yes, I'm not convinced Provider is right either. For now, it suited the
immediate need but I was planning to revisit it.
A CollectionAdapter instance can choose to implement the Transactional
interface if it wishes to support begin/end/compensate semantics.
I think this might be going a little bit overboard here in terms of
interfaces. I would rather lean toward building this into the
AbstractCollectionAdapter itself. A la the code snippet I published
earlier which called begin/end inside.
BTW, I also think we'll need to have begin/end points which we can
intercept in the actual Provider implementation itself.
Noted. Once I finish the initial port, I'll check the code into a branch
so we can collectively review it and make whatever additional tweaks we
need.
Overall, I like the simplified flow and increased coherency!
Excellent.
- James
- Dan
