dhis2-devs team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

Hi Bob

> I've finally had a chance to look more closely at what you are doing.
> Can I make a small suggestion?  Currently you are replicating a lot of
> code as you implement attributes across dataelements, indicators and
> orgunits.  Currently these all extend AbstractNameable object.

Currently, theres not too much duplication... just one added one field
called attributeValues (with getter/setter). If you're talking about
the newly committed code for making attributes/attributeMap available
(three duplications there), that code is not finished, I just had to
commit it since I'm working on something else now. Yes, that
functionality should be made more generic, as its basically doing the
same thing three times (and more times, if we also add these to
datasets, etc)

> What about creating AbstractExtendableObject which extends
> AbstractNameableObject?  Then include your  "Set<AttributeValue>
> attributeValues" and related methods in there.  Then DataElements,
> Indicators or what have you become extendable by simply extending that
> class?

Yes, I don't really want to mess too much with the original domain
classes, but making it a bit more generic is on the agenda. This is
very much WIP and more refactoring could/should happen. :)

--
Morten

> Bob
>
> On 14 September 2011 12:27, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>> Breaking out from our current hard coded set of object attributes is
>> certainly a great step forward.  There is also some advantage in
>> trying to think a bit generally about what we are doing.  We are
>> seeing lots of progress in the right direction.  I was about to start
>> a discussion about names earlier, but maybe it makes sense to consider
>> some of these things together.
>>
>> In general an entity within the dhis model universe has:
>> (i) a set of identifiers
>> (ii) a set of names
>> (iii) a set of attributes
>> (iv) a set of relations with other attributes
>>
>> One could think of names as attributes, but there are reasonable
>> semantic reasons to consider them separately.
>>
>> On top of this generic view we have classes or categories of entity.
>> Such as DataElement, OrgUnit etc, where the class of the entity
>> determines the set of attributes and the type of relations between
>> them.
>>
>> I think from an xml metadata representation perspective, this is
>> probably how it should be modelled.  The fact that some of the
>> attributes may be fixed database fields and some dynamically
>> configured attributes is incidental and purely historical.  If you had
>> the benefit of hindsight and were designing a datadictionary from
>> scratch, you might never have had the fixed fields in the database.
>> Or you might have come up with different ones.  On import/export I
>> think the distinction should simply be masked by the API.  Fixed or
>> non-fixed is an internal arrangement of little interest outside the
>> system.
>>
>> Bob
>>
>> PS.  One of the possible uses of attributes which I am seeing is the
>> in fact the possibility of dynamically adding new identifiers for
>> objects.
>>
>> On 8 September 2011 15:55, Jo Størset <storset@xxxxxxxxx> wrote:
>>> Thanks for the responses.
>>>
>>> So I guess this might very well be a start of a general evolution in the meta model? It might be worth already now thinking a little through the possible consequences of this direction going forward. I think this is something we need :)
>>>
>>> As we work through how to represent the meta model in external formats (xml and so on), this might have implications on how generic a model we should create for these formats (and I guess the attribute definitions themselves have to represented in some way). In that context it might make sense to generalize both the objects these attributes apply to and the way we represent atrributes more generally. And also at least look at and specify likely future harmonization now?
>>>
>>> Changing the external formats once they are created is much more difficult than changing implementation details, so it might be worth it to think a little bit broader already now.
>>>
>>> A minor point - when I saw the term dynamic attributes, I was immediately thinking free-form attributes (more like tags you could put on individual org units). But I guess this is about predefined attribute types applied to (specific) meta objects(?) Maybe just calling it "attributes" might be good enough, if that is what it is?
>>>
>>> Jo
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>