Re: Sharing metadata logic between parsers

[Nick Burch <ni...@alfresco.com>]

On Mon, 30 Jan 2012, Jukka Zitting wrote:
>> If we're doing that sort of thing, then I'd rather we put the logic 
>> onto the Property for that. The Property already has a type and the 
>> closed list of allowed values (as Strings, from the XMPDM 
>> specification). It would seem to me that the logic for going to/from 
>> channel numbers would best live with the strings themselves, on the 
>> property, rather than outside?
>
> I'm thinking of cases where such a convenience methods could rely on
> more than just a single property. For example, a getNumberOfPages()
> convenience method could look something like this (with an extra
> getInt(String) helper method):
>
>    int getNumberOfPages() {
>        Integer pages = metadata.getInt(PagedText.N_PAGES);
>        if (pages == null) {
>            pages = metadata.getInt(MSOffice.PAGE_COUNT);
>        }

I decided, after thinking on this a bit, that the best bet was to try to 
implement the solution and see how it actually worked

I've however just found a snag with Jukka's proposed solution above. I 
wanted to put the logic on XMPDM, as static methods, because I thought 
that the logic should really live with the property definition. 
Unfortunately, this doesn't work, as XMPDM is an interface so Java won't 
let you add random static methods. I tried putting the static method on 
Metadata itself, but I really didn't like the look of it

Property itself is final, as we don't want people to go around adding 
extra types in that the specifications don't support, so I can't simply 
add a converter method onto that.

In r1242018 I've committed a couple of different possible ways to do the 
conversion, which do work, so people can have a look and a think. I could 
see the static class being attached optionally to the Property, for either 
explicit calling, or implicit as Ray described.

Based on how it looks now I've actually coded something, I'm leaning 
towards implicit conversion in metadata.set(Property, thing) calling 
methods on an optional attached converter on the property. (I guess Ray 
would be in favour of this, as it's quite like his idea!).

Thoughts? Should I go ahead and try to implement my plan, so we can see if 
we like how it looks in real code and if there are any problems with doing 
it? Can anyone think of a cleaner way to do it? Can anyone think of a way 
to do what Jukka suggested, but without having to clutter up the main 
concrete class?

Cheers
Nick