← Back to team overview

dhis2-devs team mailing list archive

Re: Conflicts merging databases

 

Trimming is certainly the least that we should do. I have recently
come up against a problem with some sort of tick marks (UNICODE 0x92)
which look like apostrophes (which are bad enough) but are not. These
seem to get inserted from copy/paste from Excel or Word who
conveniently changes normal apostrophes to these weird characters
which are not, but may appear to the user to be.

Trim is a good start, but we still need think about  more strict
(regex) validation.

Regards,
jason


On Fri, Aug 19, 2011 at 3:35 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
>
> On Fri, Aug 19, 2011 at 3:16 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> On 19 August 2011 14:14, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>> > On 19 August 2011 13:49, Ola Hodne Titlestad <olati@xxxxxxxxxx> wrote:
>> >> 2011/8/19 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>> >>>
>> >>> Yes I've seen this on a number of databases as well - causing trouble
>> >>> with mydatamart.  Do you think we should "discourage" this workaround
>> >>> by trimming on save?  I can understand the frustration that might have
>> >>> lead people to do this, but it is better to use Male_ or _Male or the
>> >>> like than just adding whitespace.
>> >>>
>> >>
>> >> Good idea to trim on save, I support that.
>> >
>> > Well there would be quite a few fields to trim and a few places to do
>> > it.  It could be done at javascript level, but probably better in the
>> > model.  Eg changing AbstractIdentifiableObject.java setter to:
>> >
>> > public void setName( String name )
>> >    {
>> >        this.name = name.trim();
>> >    }
>> >
>> > Would catch a whole lot of critical objects.  Something similar on
>> > "code" for orgunits would fix up a bundle of apparent mismatches with
>> > the master facility list as well.
>>
>> Sorry that is a Kenya-specific reference for those who were wondering :-)
>>
> The exact term may be somewhat Kenya specific, but it is generic enough that I think it is quite suitable for our general discussion and could also be used in the manual (I think it has been adopted by WHO for their work on Service Availability and Readiness Assessment (SARA), aka SAM:
>
> http://www.who.int/healthinfo/systems/serviceavailabilitymapping/en/
>
> A largely equivalent term would be facility registry. I think we should introduce some of this vocabulary into our implementation manual (if it's not there already), to link with the overall Enterprise Architecture thinking (while keeping things concrete and understandable and mostly avoiding mystifying or technical/academic jargon such as the term "Enterprise Architecture" itself).
>
> Evidently, in many countries DHIS2 will serve as the de facto registry for both facilities and aggregate data elements/indicators, but this is not the case everywhere, and metadata synchronization both between DHIS2 instances (as highlighted by the ongoing discussion on offline installs) and with other systems through third party registries will be crucial. You of course know this best of all Bob, but I still thought it worth highlighting on this list in light of my current work.
>
> Knut
>
> _______________________________________________
> 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
>


Follow ups

References