incubator-chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Hubick (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CMIS-114) APPObject's lack APP specific typesafe methods
Date Fri, 12 Feb 2010 00:34:27 GMT

    [ https://issues.apache.org/jira/browse/CMIS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832758#action_12832758
] 

Chris Hubick commented on CMIS-114:
-----------------------------------

Hmm.

I just wanted to query my CMIS enabled repository, and lacking much documentation, I happily
stumbled into Chemistry by looking into the "chemistry-api" module, and the "Repository" interface
seemed to offer access to the type of information I needed, so I just went with it.  I saw
I could use APPContentManager to get a Repository interface reference, given a CMIS URL, and
started out by just trying to just use the higher level CMISObject derived interfaces (Folder/Document)
it exposed.  That was working OK until I found out I needed access to some lower level things,
like the URL of the Document from the server, which I could see through the debugger was stored
internally, but the Document API didn't expose.  So I switched to the APPObject derived interfaces
and used those to gain access to the underlying APPObjectEntry and get the info I needed.
 It was just that, since the introduction of Java Generics, I cringe when I see myself cast'ing,
so this bug/patch was just a reaction to that, and hopefully to help out a bit.

I don't really understand, or at least haven't really thought much about the overall API design
in this area.  When you say "one of the goals of Chemistry was to hide the underlying transport"
- one would initially hope the JCR API could serve as that single general purpose repository
API, and that introduction of an alternate API for users to code against wouldn't be necessary.
 In reality, I can see how CMIS specific extensions to JCR might be required to expose all
functionality, or how an entirely new alternate CMIS-specific API would be required, or at
least how the JCR implementation could desire an internal API which aligns more closely with
native CMIS functionality.

But between JCR, CMISObject derivatives, APPObjectEntry, and SPI - there seems to be more
levels of abstraction than I would have expected here (given my simple use case), which I
don't fully understand the reasoning for, and don't feel qualified to comment on.  However,
this does make me wonder if I should be coding against JCR directly, rather than the Chemistry
specific API which I have been?  Should everything besides JCR be avoided as an internal implementation
detail?  Are users even expected to need access to CMISObject or APPObject interfaces?  If
I need access to some information item available over CMIS, not currently exposed through
JCR, should I be filing bugs/patches on that instead?

If it is expected that all CMIS information be somehow accessible through JCR or CMISObject
derived API's, then you can certainly mark this bug invalid.

If it is expected that for some information requirements, users could reasonably be expected
to require use of APPObject derived API's directly, then I think providing a cast free API
would be best.  I personally tend to err on adding any such burdens to the common library
API, making it the best interface you can for all valid uses, and thus lifting those burdens
off the shoulders of all the users.  Ie, having a little extra code in a single reusable library
is better than having many many users writing hacky cast's.

It's totally your call though - I was just trying to help, and maybe bring attention to a
what I thought might be a valid use-case that hadn't been considered in the design.


> APPObject's lack APP specific typesafe methods
> ----------------------------------------------
>
>                 Key: CMIS-114
>                 URL: https://issues.apache.org/jira/browse/CMIS-114
>             Project: Chemistry
>          Issue Type: Improvement
>          Components: atompub
>            Reporter: Chris Hubick
>            Priority: Minor
>         Attachments: chemistry_app_type_safety.patch
>
>
> Hi.
> When using APPContentManager to communicate with my repository, I would like to use the
APPObject derived API's, in order to access underlying APP specific information (Link's, etc).
 The problem is that I end up writing a lot of code containing ugly object cast's like this:
> APPContentManager contentManager = new APPContentManager("");
> APPRepository repository = (APPRepository)contentManager.getDefaultRepository();
> APPConnection connection = (APPConnection)repository.getConnection(null);
> APPFolder aFolder = (APPFolder)connection.getFolder("");
> When I would rather have the ability to write typesafe code like this:
> APPContentManager contentManager = new APPContentManager("");
> APPRepository repository = contentManager.getDefaultAPPRepository();
> APPConnection connection = repository.getAPPConnection(null);
> APPFolder aFolder = connection.getAPPFolder("");

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message