Historically the purpose of getShortestName was explicitly so that jsp pages
could say
${concept.shortestName}
instead of having to do:
<c:choose>
<c:when test="${not empty
concept.shortName}">${concept.shortName}</c:when>
<c:otherwise>${concept.name}</c:otherwise>
</c:choose>
Wyclif, the default behavior of all methods should be that if you're in
'en_GB', and the concept only has a name in 'en', you get that. This should
not be something they have to (or even have the option to) get only en_GB
but not en.
We should probably provide *one* convenience method that lets you get names
for a precise locale (purely for use in an Edit Concept UI), but we should
not be giving this option to regular API users unless they look hard for it.
Because 99% of the time they want "get the name compatible with my locale".
-Darius
On Wed, Sep 21, 2011 at 6:04 PM, Burke Mamlin <[email protected]>wrote:
> There is a semantic difference between "getShortName" and
> "getShortestName". The "short name" in OpenMRS was created as an explicit
> way of defining a representation (term) for a concept that would work for
> constrained spaces (e.g., column name in an export, the column in a
> flowsheet of results, etc.)… like the abbreviation "HGB" for HEMOGLOBIN.
>
> "getShortestName" suggests "get me the shortest name of those available",
> which might be similar, but a different question. Does "getShortestName"
> consider "short name" as one of its choices? Maybe not, since "short name"
> might be a contrived abbreviation created as a compromise to meet the needs
> of a spreadsheet and a valid synonym.
>
> -Burke
>
>
> On Wed, Sep 21, 2011 at 10:49 AM, Mark Goodrich <[email protected]> wrote:
>
>> Wyclif,****
>>
>> ** **
>>
>> Well, not exactly.****
>>
>> ** **
>>
>> getBestShortName now delegates to getShortestName(Locale locale, false) .
>> The logical of getShortestName() seems a little bizarre to me, frankly.**
>> **
>>
>> ** **
>>
>> First, getShortestName tries calling getShortNameInLocale(Locale locale).
>> getShortNameInLocale fetches the first concept name tagged “short” that
>> matches the passed locale. This makes sense as a first pass, but if no
>> exact locale match is found (i.e. a locale with both a country and language
>> match) , getShortNameInLocale returns null… it doesn’t try language or
>> country-only matches.****
>>
>> ** **
>>
>> If getShortestName gets a null return value from getShortNameInLocale, the
>> method then finds 1) the literal shortest name for the specified locale
>> (again, using exact locale matches) via string length comparisons, and also
>> finds 2) the literal shortest name overall. If the “exact” Boolean is set
>> to “true”, #1 is returned, but if it is set to false #2 is returned (even if
>> #1 is not null).****
>>
>> ** **
>>
>> So, if I have the following concept names defined for the same concept***
>> *
>>
>> ** **
>>
>> Giant cat, en****
>>
>> Cat, en, tagged short****
>>
>> Gato gigante, es****
>>
>> Gato, es, tagged short****
>>
>> ****
>>
>> And I do a getBestShortName(new Locale("es_ES")), it returns "Cat",
>> because there is no exact match for es_ES, and Cat is shorter than Gato.
>> If, as Ben suggests, we change getBestName to delegate to
>> getShortestName(locale, TRUE), the call would now return null. Previously,
>> it would return Gato, which seems like the correct behavior.****
>>
>> ** **
>>
>> Mark ****
>>
>> ****
>>
>> ** **
>>
>> ** **
>>
>> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Wyclif
>> Luyima
>> *Sent:* Tuesday, September 20, 2011 6:11 PM
>> *To:* [email protected]
>> *Subject:* Re: [OPENMRS-DEV] Change in fetching Concept names for a
>> Locale between 1.6 and 1.8****
>>
>> ** **
>>
>> Mark, the methods they delegate to encapsulate the same logic and even
>> more because of the extra argument they take in that specifies whether other
>> locales should be searched.****
>>
>> ** **
>>
>> Wyclif****
>>
>> On Tue, Sep 20, 2011 at 5:43 PM, Mark Goodrich <[email protected]> wrote:
>> ****
>>
>> Looks like there was a change in the methods on Concept for fetching a
>> Concept Name for a Locale between 1.6 and 1.8.
>>
>> In 1.6 the following two methods existed:
>>
>> getBestShortName(Locale)
>> getBestName(Locale)
>>
>> These methods had fairly intelligent logic for fetching a name based on
>> locale... specifically, they would check separately for matches between the
>> language and country components of a locale. For instance, if you had a name
>> "Some Name" for the locale "en", and you did a getBestShortName(new
>> Locale("en_GB")), the methods were smart enough to return the "Some Name" as
>> the name if no name for the exact locale en_GB was found.
>>
>> In 1.8 these methods have been depreciated, and now delegate to methods
>> that only match on exact locales (getBestShortName(new Locale("en_GB") would
>> return null in the previous example).
>>
>> Was there a reason for this? It looks like there are methods
>> getShortNameInLanguage and getShortNameForCountry that I can use to
>> approximate the previous functionality, but these methods have been
>> depreciated as well. Am I missing something?
>>
>> Thanks,
>> Mark
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [email protected] with "SIGNOFF openmrs-devel-l" in the body
>> (not the subject) of your e-mail.
>>
>> [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]****
>>
>> ** **
>> ------------------------------
>>
>> Click here to
>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>> OpenMRS Developers' mailing list
>> ****
>> ------------------------------
>> Click here to
>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>> OpenMRS Developers' mailing list
>>
>
> ------------------------------
> Click here to
> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
> OpenMRS Developers' mailing list
>
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
