chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Cornwell <gavin.cornw...@alfresco.com>
Subject Re: ObjectiveCMIS browser binding comments
Date Tue, 22 Apr 2014 08:10:13 GMT
Hi Peter,

No problem, moving the UriBuilder classes is one of the re-factoring items I’d suggested
(if it still makes sense) so I’ll take a look when I undertake that task (I had hoped to
get it done over Easter but clearly that didn’t happen!)

Thanks for all your efforts so far.

Regards,

Gavin



On 22 Apr 2014, at 08:48, Sutter, Peter <peter.sutter@sap.com> wrote:

> Hi Gavin,
> 
> you can give it a try but then we have to write it in a generic way that
> we can use it for all methods :)
> 
> Best regards,
> Peter
> 
> 
> 
> On 4/21/14, 10:31 PM, "Gavin Cornwell" <gavin.cornwell@alfresco.com> wrote:
> 
>> Hi Peter,
>> 
>> Yep, the two properties on RepositoryInfo are not used currently and are
>> actually stored in the binding session (as they are in the atompub
>> binding) so I would definitely suggest removing them.
>> 
>> Yes, I see the CMISURLUtil is used consistently in all methods, but we
>> are repeating the same code a lot which the builder objects encapsulate.
>> Could we not pass the browser binding specific part of the URL into the
>> builder object as the template URL (i.e. the output of the get methods
>> you added to the base service class) and have the builder object just add
>> the common parameters? Alternatively, we could have a browser binding
>> UriBuilder subclass?
>> 
>> Hope you had a good Easter holiday by the way!
>> 
>> Regards,
>> 
>> Gavin
>> 
>> Sent from my iPad
>> 
>> 
>>> On 18 Apr 2014, at 12:01, "Sutter, Peter" <peter.sutter@sap.com> wrote:
>>> 
>>> Hi Gavin,
>>> 
>>> thanks for your feedback. Yes those constants should be move to the
>>> CMISBroserConstants header file.
>>> 
>>> Yup there should be rather a browser binding subclass for the
>>> RepositoryInfo that holds those two properties. I will do that (or will
>>> remove it as those properties are currently not used).
>>> 
>>> In fact when I started with the browser binding implementation I have
>>> used
>>> the UriBuilder classes where possible but I had to extend them for other
>>> properties like succinct and so on but I could not reuse those classes
>>> for
>>> all the methods so I went for the CMISURLUtil which is now used
>>> consistent
>>> in all methods.
>>> 
>>> Same here in germany with the public holidays, so happy easter holidays
>>> :)
>>> 
>>> Best regards,
>>> Peter
>>> 
>>> 
>>> 
>>>> On 4/18/14, 12:02 AM, "Gavin Cornwell" <gavin.cornwell@alfresco.com>
>>>> wrote:
>>>> 
>>>> Hi Peter,
>>>> 
>>>> You¹ve made great progress already, I just have a few
>>>> questions/comments
>>>> about the changes made in revision 1588209.
>>>> 
>>>> There are a couple of browser binding constants in CMISConstants.h
>>>> (kCMISParameterSelector & kCMISParameterSuccinct), can you please move
>>>> these to CMISBrowserConstants.h?
>>>> 
>>>> rootFolderUrl and repositoryUrl properties have been added to
>>>> RepositoryInfo. This object should match the definition of
>>>> RepositoryInfo
>>>> in the CMIS spec, furthermore, these properties are browser binding
>>>> specific and don¹t appear to be used. I think we should keep this
>>>> object
>>>> completely generic (as it is in OpenCMIS).
>>>> 
>>>> Is there a reason why you haven¹t used the UriBuilder objects to
>>>> construct the URLs in the service methods i.e. in retrieveChildren and
>>>> retrieveObject?
>>>> 
>>>> Please note it¹s a public holiday in the UK tomorrow and Monday so
>>>> responses might be delayed more than usual ;-)
>>>> 
>>>> Regards,
>>>> 
>>>> Gavin
>>> 
> 


Mime
View raw message