[
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.
