Hi, Am 30.07.2012 um 14:18 schrieb Mike Müller:
>>> A little bit late... >>> I find it quite natural to first set the changes with put and remove and >>> after that call update to make the changes persistent. That's very similar >>> to how OR mappers or also JCR with the session works. >>> But if I get you right, after the call of update on the ModifiableValueMap >>> the changes (for JCR) are only in the session and not saved. You also >>> have to call commit on the ResourceProvider. That could be a good >>> thing if we really want to support transactions in the future. But it means >>> also that the ResourceProvider has to be known by the user which changes >>> the resource. >> >> Actually the user calls the commit method on the ResourceResolver which >> forwards >> that to the ResourceProviders internally. Clients/users never interact with >> ResourceProviders directly -- they can't, since they don't know them. > > Ok, in this case we expect that there's only one ResourceResolver, otherwise > we can't decide which ResourceResolver we should call. Is that correct, or is > it possible that we have more than one ResourceResolver in the future? Well, there is a ResourceResolverFactory service from which ResourceResolver instances can be retrieved. Technically there may be more than one ResourceResolverFactory services but practically, there won't. Specifically during request processing there is the ResourceResolver available from SlingHttpServletRequest.getResourceResolver which is used during processing. Regards Felix
