Hi, Am 30.07.2012 um 12:59 schrieb Carsten Ziegeler:
> Hi, > > 2012/7/30 Felix Meschberger <[email protected]>: >> Hi all, >> >> I just had a quick look at the current (Rev. 1366999) of the Resource API >> (o.a.s.api.resource) and have some remarks on that: > > Thanks, really appreciated! The whole stuff is still a work in > progress (although it should be functional right now). >> >> * What is the behaviour of the deprecated PersistableValueMap ? Will >> the save method still persist changes (Session.save() in JCR speak) ? > Yes, we don't change the behaviour here. > >> >> * What is the spec of the exceptions declared on the new ResourceResolver >> methods (delete, addChild) ? > They throw NPE if required arguments are null, they throw an > unsupported op exception if the path of the resource is not handled by > a modifying resource provider. > PersistenceException is thrown if something goes wrong. > >> >> * The new ResourceResolver methods commit and revert are spec-ed without >> exceptions (except PE on commit). Could there be exceptions thrown like >> UnsupportedOperationException ? > No, I don't think so - the resolver just delegates to modifying > providers. So even if there is no modifying provider, commit or revert > do not throw unsupported operation exception as this is the same > situation as if there are modifying providers but no changes. > >> >> * I think the ResourceResolver.addChild method should be caled "create" >> and the syntax of the "name" argument be defined: is this a simple >> name (without slash characters) or a relative path ? If relative path, >> what about missing intermediate nodes ? > The "name" argument is a name without a slash - an exception is thrown > in this case. > That's why Bertrand suggested to name this method addChild instead of > create to make it clear that the string argument is more a name than a > path. Hmm, ok. But this naming looks odd with all the standard terms like get, put, delete we use and then there's the special term "addChild". In general I would think "add" always comes with "remove" (and vice versa) while "delete" comes with "create" (and vice versa). More specifically, this whole thing is about "CRUD" where "C" is "create" and not "add" ;-) > I'm fine with addChild and I would be fine with create as well. > >> >> * The JavaDoc of ResourceProviderFactory methods should be fixed (they >> look like copied from ResourceResolverFactory) > I think they are :) I'll do that. > >> >> * On QueriableResourceProvider: >> - I think null is a valid result indicating non-support for >> the query language. No results would probably require an empty >> iterator. > Good idea. > >> - Thus unsupported query languages just cause the methods to >> to return null. > Yepp > >> - A service property should be added (String or String[]) indicating >> the query languages supported by the service. For >> ResourceProviderFactory provided QueriableResourceProvider >> instances this property must be defined on the >> ResourceProviderFactory service. > Agreed. > > I'll clarify the javadocs and add the prop. Cool. Thanks. Regards Felix > > Thanks > Carsten >> >> WDYT ? >> >> Regards >> Felix > > > > -- > Carsten Ziegeler > [email protected]
