Hi, Am 29.07.2012 um 15:06 schrieb Mike Müller:
> Hi > > 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. > Further, if someone likes to create a new resource the > right ResourceProvider also has to be known, to call create on it. Same > case if you want to delete a resource, because the delete method is on > the ResourceProvider. Wouldn't it be easier if the delete method is on > the resource and the update method on the ModifiableValueMap makes > the changes really persistent. If we decide to introduce transactions in > the future we could extend these methods and hand over a context > object for the transaction or something like that. The ResourceResolver selects the appropriate ResourceProvider using resource path best match in the same way as done for the accessing (reading) the resources. Hope this helps. Regards Felix > > Please pardon me if I got something incorrect, but isn't it the same case > if I want to create a new resource: I have to know the right > ResourceProvider to call create on it. Shouldn't Sling provide some > help and call the right ResourceProvider for you? > > best regards > mike > > > >> -----Original Message----- >> From: Carsten Ziegeler [mailto:[email protected]] >> Sent: Wednesday, July 18, 2012 9:31 AM >> To: [email protected] >> Subject: [RT] API for modifying resources >> >> Hi, >> >> I'm currently working on CRUD support for Sling based on the resource >> API. Current trunk contains already a version of it. >> I'm wondering what the best api for modifying resources is. >> >> Right now, the idea is to adapt a resource to ModifiableValueMap which >> is an extension of the ValueMap. Like the PersistableValueMap this map >> collects all changes internally. It provides an update() method which >> pushes the changes into the transient persistence layer (e.g. jcr >> session). A call to the resource resolver finally persists all >> transient changes (let's forget about different resource providers and >> transactions for now) >> This approach has the advantage to reuse the map interface to change >> values, no exceptions are thrown on put and remove. - but it requires >> to additional calls, update on the map and commit on the resource >> resolver to get the changes persisted. >> >> I thought of changing this and push each change directly into the >> transient store, so a call to put() or remove() on the map is directly >> pushed through - this avoids the extra call to update(), however put() >> and remove() have no checked exceptions declared. So we can either >> throw undeclared exceptions (which I think is not really a good idea >> in this case) or defer exception throwing until the commit call on the >> resource resolver. But obviously this gets nasty if e.g. a put() is >> not successful, doesn't throw an exception and one is doing a get on >> the same property etc. >> >> So, final solution would be to add special methods like set and delete >> which might throw PersistenceException - and avoid reuse of modifying >> methods from the map interface. Simpler to use compared to the current >> version in trunk but additional methods. >> >> Right now I'm undecided between the first and the last solution - with >> a slight preference of the current version from trunk. >> >> But maybe there are other/better options? >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> [email protected]
