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 <knu...@gmail.com> wrote:
>
> On Fri, Aug 19, 2011 at 3:16 PM, Bob Jolliffe <bobjolli...@gmail.com> wrote:
>>
>> On 19 August 2011 14:14, Bob Jolliffe <bobjolli...@gmail.com> wrote:
>> > On 19 August 2011 13:49, Ola Hodne Titlestad <ol...@ifi.uio.no> wrote:
>> >> 2011/8/19 Bob Jolliffe <bobjolli...@gmail.com>
>> >>>
>> >>> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help : https://help.launchpad.net/ListHelp
>
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
