FWIW, the "short name" for a concept may not necessarily be the shortest name. If the admin wants a 5-character term to be displayed in flowsheets & as the column name in spreadsheets despite their being a 3- or 4-character synonym, they can set the concept's short name to the 5-character term.
-Burke On Wed, Sep 21, 2011 at 3:14 PM, Darius Jazayeri <[email protected]>wrote: > 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 >> > > ------------------------------ > 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]
