On 28 Apr 2009, at 11:31, Dominique Pfister wrote:
Just a quick thing I noticed while working on a JCR implementation of your API, in the methods that return collections, e.g.:List<ObjectEntry> getChildren(String folderId, BaseType type, String filter, boolean includeAllowableActions, boolean includeRelationships, int maxItems, int skipCount, String orderBy, boolean[] hasMoreItems); Instead of having this extra boolean-array parameter "hasMoreItems" in order to return more than one value from this method, don't you think it'd be more appropriate to create a new class for the return type, containing both the collection and this flag?
Yes, it would certainly be more object oriented. Currently the call sequence is very C-like, because in the initial version I wanted to have something lean without drowning into additional DTO classes. But certainly, in a coming refactoring we'll provide a small class to wrap whatever results are needed. There's another place where I used a similar passing style, boolean contentCopied[] for the checkIn() method. Here too I'll put a proper class to be OO.
I did not see where this argument was actually used, so would it even be possible to entirely omit it?
It's not used yet but it's specified by the CMIS domain model definition and the protocol bindings, so it'll get used eventually.
Keep in mind that this getChildren method is part of the low-level SPI (which you have to implement for a new backend of course), in actuality an application user will just see the Folder.getChildren() method whose API is much simpler. I'm finishing up a cleaner separation of API from SPI that I'll commit in our Mercurial this afternoon, and anyway we'll talk about this more in Basel tomorrow I hope.
Regards, Florent -- Florent Guillaume, Head of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
