dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 14 September 2011 14:05, Morten Olav Hansen <mortenoh@xxxxxxxxx> wrote:
> 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. :)

Sure.  I know.

I'm just making sure I keep in touch because I'm also in the process
of working out how best to represent these things for the purpose of
of importing/exporting them.  So what you do here has some significant
bearing on what I do.  The few bits of duplication you have currently
will fan out further when we serialize/deserailize to xml.

Can I suggest we fit in a brief design call this week to touch base?
I have a freeconference number we can use.  Maybe tomorrow or Friday?
Lars are you around and/or available as well?

Regards
Bob


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