Initial ObjectiveCMIS browser binding commit

[Gavin Cornwell <ga...@alfresco.com>]

Hi,

As you may have seen I have just committed my initial skeleton implementation of the browser binding to the "browser-binding" branch of ObjectiveCMIS.

All services that have been implemented for the AtomPub binding are stubbed out, each unimplemented method throws an exception.

All JSON properties have been defined as constants in CMISBrowserConstants and all parsing is currently performed in CMISBrowserUtil.

I've removed any binding specific items from CMISBindingSession, this class (in my opinion) should remain binding agnostic. The atom pub constants were moved to the CMISAtomPubConstants class and I've renamed the "kCMISBindingSessionKeyAtomPubUrl" constant to "kCMISBindingSessionKeyUrl".

Tests obviously require a server that supports the browser binding and requires a new key called "binding" set to "browser" in the configuration, for example:

<dict>
   <key>username</key>
   <string>admin</string>
   <key>password</key>
   <string>admin</string>
   <key>url</key>
   <string>http://localhost:8080/alfresco/api/cmis/versions/1.1/browser</string>
   <key>repositoryId</key>
   <string>-default-</string>
   <key>binding</key>
    <string>browser</string>
</dict>

The first four tests are passing. My approach so far has been to take each test as it comes and implement the underlying methods that are required to make it pass.

There's obviously still lots to do (marked as such in the code) and this exercise has also highlighted some re-factoring I would like to suggest we do:

- Several classes that are using "id" and "description" as property names, we should change these as they have other meanings in ObjectiveC
- All AtomPub related classes should be renamed to include the word Atom
- All the URIBuilder classes should be moved up a folder as I don't think they are specific to AtomPub, they could be re-used across other bindings

We can discuss this and the approach for implementing the rest of the binding in our next status call, which I'll arrange first thing next week.

Regards,

Gavin

Re: Initial ObjectiveCMIS browser binding commit

["Gross, Lukas" <lu...@sap.com>]

Hi,

This sounds awesome. We'll have a look at the branch as soon as we have
some time (probably tomorrow).
So far I totally agree with your suggestions. However we should
definitively have a call next week to discuss the next steps and to assign
a first bunch of tasks :)

Regards,
Lukas

On 3/29/14 11:08 PM, "Gavin Cornwell" <ga...@alfresco.com> wrote:

>Hi,
>
>As you may have seen I have just committed my initial skeleton
>implementation of the browser binding to the "browser-binding" branch of
>ObjectiveCMIS.
>
>All services that have been implemented for the AtomPub binding are
>stubbed out, each unimplemented method throws an exception.
>
>All JSON properties have been defined as constants in
>CMISBrowserConstants and all parsing is currently performed in
>CMISBrowserUtil.
>
>I've removed any binding specific items from CMISBindingSession, this
>class (in my opinion) should remain binding agnostic. The atom pub
>constants were moved to the CMISAtomPubConstants class and I've renamed
>the "kCMISBindingSessionKeyAtomPubUrl" constant to
>"kCMISBindingSessionKeyUrl".
>
>Tests obviously require a server that supports the browser binding and
>requires a new key called "binding" set to "browser" in the
>configuration, for example:
>
><dict>
>   <key>username</key>
>   <string>admin</string>
>   <key>password</key>
>   <string>admin</string>
>   <key>url</key>
>   
><string>http://localhost:8080/alfresco/api/cmis/versions/1.1/browser</stri
>ng>
>   <key>repositoryId</key>
>   <string>-default-</string>
>   <key>binding</key>
>    <string>browser</string>
></dict>
>
>The first four tests are passing. My approach so far has been to take
>each test as it comes and implement the underlying methods that are
>required to make it pass.
>
>There's obviously still lots to do (marked as such in the code) and this
>exercise has also highlighted some re-factoring I would like to suggest
>we do:
>
>- Several classes that are using "id" and "description" as property
>names, we should change these as they have other meanings in ObjectiveC
>- All AtomPub related classes should be renamed to include the word Atom
>- All the URIBuilder classes should be moved up a folder as I don't think
>they are specific to AtomPub, they could be re-used across other bindings
>
>We can discuss this and the approach for implementing the rest of the
>binding in our next status call, which I'll arrange first thing next week.
>
>Regards,
>
>Gavin
>