Simple things could help:
a) I don't want to collapse property definition classes, because they have type
dependent methods. But it would help just to move them into a separate package.
The use case is intellisense feature of the IDE. Currently it is hard to select
what you want.
b) All interfaces derived from PropertyData do not really extend the interface.
E.g. PropertyDataTime extends PropertyData<GregorianCalendar>{}. Isn't it
sufficient just to have PropertyData<T>?
Regards,
Stephan
-----Original Message-----
From: Florian Müller [mailto:fmuel...@opentext.com]
Sent: Mittwoch, 12. Mai 2010 17:02
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation
CMIS defines almost 200 different structures. So, 50 interfaces for the CMIS
Bindings API sounds reasonable.
Even if we consolidate a few (which doesn't make them more useable!), the
magnitude will not change.
What's the issue? The size of the Jar? The Client API user will only deal with
a few of them.
Florian
-----Original Message-----
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com]
Sent: Mittwoch, 12. Mai 2010 16:34
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation
Hi,
I'm also interested into this discussion. There is a general issue with package
*.commons.api that contains more than 50 interfaces (!). Removing unnecessary
interfaces and re-structuring would make sense.
Regards,
Stephan
-----Original Message-----
From: Florian Müller [mailto:fmuel...@opentext.com]
Sent: Mittwoch, 12. Mai 2010 16:01
To: chemistry-dev@incubator.apache.org
Subject: RE: [jira] Resolved: (CMIS-124) Client Runtime Implementation
That doesn't really sound object oriented...
We should discuss this later with some use cases.
Florian
-----Original Message-----
From: Florent Guillaume [mailto:f...@nuxeo.com]
Sent: Mittwoch, 12. Mai 2010 15:35
To: chemistry-dev
Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation
I know but it's rather easy to add all of:
T getMinValue();
T getMaxValue();
BigInteger getMaxLength();
DecimalPrecision getDecimalPrecision();
DateTimeResolution getDateTimeResolution();
on the single PropertyDefinition class, and make them throw exceptions
when not called on the suitable kind of property.
Florent
On Wed, May 12, 2010 at 3:20 PM, Florian Müller <fmuel...@opentext.com> wrote:
> Hi Florent,
>
> The Property*Defintion interfaces are actually different and cannot be
> collapsed. Compare PropertyDateTimeDefinition with PropertyDecimalDefinition,
> for example.
>
>
> - Florian
>
> -----Original Message-----
> From: Florent Guillaume [mailto:f...@nuxeo.com]
> Sent: Mittwoch, 12. Mai 2010 14:49
> To: chemistry-dev
> Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation
>
> Yes, with use there's some things that may appear as suboptimal in the
> current API and we cannot promise no changes. But nothing
> revolutionary will come I'm sure.
>
> As an example of changes that may or may not appear:
>
> I don't like this part of the high-level API and find it hard to use:
> <T> T getPropertyValue(String id);
> <T> List<T> getPropertyMultivalue(String id);
>
> After the first release is done, I'll propose to change it to:
> <T> T getPropertyValue(String id);
>
> Which would returns a single value for a single-valued property, and a
> list for a multi-valued property.
>
>
> I'd also like to fold all the PropertyDecimalDefinition,
> PropertyStringDefinition, etc. into the single PropertyDefinition<T>
> because the sub-interfaces don't add much IMHO. Proposal to come.
>
>
> (I'm not proposing to do it earlier as I really want a first release
> out the door and have little enough time to work on this right now...
> and I'm in vacation for the next 10 days.)
>
> Florent
>
>
>
> On Sun, May 9, 2010 at 6:52 PM, Florian Müller <fmuel...@opentext.com> wrote:
>> Hi Ugo,
>>
>> "Somewhat stable" is the right term. Most of the merger refactoring tasks
>> are done. Only the type manager implementation is still missing.
>>
>> I cannot promise that there will no changes within the next weeks, but we
>> certainly will not redesign the API.
>>
>>
>> - Florian
>>
>>
>> -----Original Message-----
>> From: Ugo Cei [mailto:u....@sourcesense.com]
>> Sent: Freitag, 7. Mai 2010 19:18
>> To: chemistry-dev@incubator.apache.org
>> Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation
>>
>>
>> On May 7, 2010, at 3:44 PM, Florian Müller wrote:
>>
>>> Hi Ugo,
>>>
>>> It's there for quite some time now.
>>>
>>> This page explains how you get and compile it: [1]
>>> The API introduction pages [2] and [3] are a bit out-of-date. The basics
>>> are still valid but some names have changed.
>>
>>
>> Thank you. What I actually would like to know is whether the current APIs
>> are considered somewhat stable, after the Chemistry/OpenCMIS merge. I can
>> live with an incomplete and buggy implementation (and try to contribute
>> fixes, as much as possible), but less so if a complete redesign is still in
>> the pipeline.
>>
>> Ugo
>>
>> --
>> Ugo Cei
>> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>>
>>
>
>
>
> --
> Florent Guillaume, Director 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
>
--
Florent Guillaume, Director 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
