> On Wed, Mar 6, 2013 at 4:32 PM, Mike Müller <[email protected]> wrote: > > ...A ResourceProviderDecorator couldn't do the job, because some operations > > are on the ResourceResolver at the moment (delete, create but also > > findResources > > and queryResources).... > > Does that indicate that those operations should be on the > ResourceProvider instead?
I don't think so. If someone changes a resource it's not important from which provider the resource is provided. In addition with the methods revert and commit on the ResourceResolver we could implement transactionality over more than one provider (even if I don't think we want to do that). The idea here is: The ResourceResolver selects the appropriate ResourceProvider using resource path best match in the same way as done for the accessing (reading) the resources. Clients/users never interact with ResourceProviders directly -- they can't, since they don't know them. This is from [1] [1] http://markmail.org/message/yj4strsk5eva7erd Best regards mike
