dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 19 August 2011 14:58, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
> 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.

Agree.  But I think there is a subtle difference.  Regarding
leading/trailing whitespace I think its ok to just trim and save.
Regarding dodgy characters within the string I don't think we can just
silently deal with them.  At the level of the setter in the model an
exception would need to be thrown and handled somewhere.

The general logic in our model mostly presupposes that all data is
good and this sort of validation is handled in user interface, which I
think trips us up from time to time all over the place.   Lars has
indicated recently that we need to do a due diligence of our model in
a more general sense and I would see this sort of validation as part
of that exercise of building robustness into the model by making it
inherently coherent and reactive (throws exception) to attempts do
evil upon it.

Bob

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