When I set a field that is a controlled list as a summary field I get the id string of the controlled list term instead of the text string. In other words, "needsnowork" is the summary value shown in the UI and not the more readable form "Needs no work" string. This is taken from the app layer config for the procedure I'm developing: <option id="needsnowork">Needs no work</option>. Is there any way to have the actual text string and not the id string display in the UI? FWIW, I'm using v2.6 code. Thanks, - Jesse

Currently, the UI is saving the static termList references only by their optionlist value, and not as a refName. The displayName is stored with the refName for this reason. If we want to update the UI to store the refNames, then you could get the Display Name in search results. However, I am not sure what chaos that would cause in the HTML DOM (i.e., having the value be a URI, and not an alphanumeric string). Yura can speak to this. I seem to remember Susan asking about this as well. Patrick > -----Original Message----- > From: Work [mailto:work-bounces@lists.collectionspace.org] On > Behalf Of Jesse Martinez > Sent: Wednesday, October 24, 2012 10:23 AM > To: CollectionSpace Work list; CollectionSpace Talk List > Subject: [Work] setting a controlled list field as a summary field > > When I set a field that is a controlled list as a summary > field I get the id string of the controlled list term instead > of the text string. > In other words, "needsnowork" is the summary value shown in > the UI and not the more readable form "Needs no work" string. > This is taken from the app layer config for the procedure I'm > developing: <option id="needsnowork">Needs no work</option>. > > Is there any way to have the actual text string and not the > id string display in the UI? > FWIW, I'm using v2.6 code. > > Thanks, > > - Jesse > > _______________________________________________ > Work mailing list > Work@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/work_lists.c > ollectionspace.org >

Did a quick trial on at least one play site (w3schools), and it had no problem with a uri with display name as the option value attribute value. Yura? What's the reason why we use the shorter form? It is certainly simpler, including on input. But it does have this drawback. Patrick > -----Original Message----- > From: Work [mailto:work-bounces@lists.collectionspace.org] On > Behalf Of Patrick Schmitz > Sent: Wednesday, October 24, 2012 11:12 AM > To: 'Jesse Martinez'; 'CollectionSpace Work list'; > 'CollectionSpace Talk List' > Subject: Re: [Work] setting a controlled list field as a summary field > > Currently, the UI is saving the static termList references > only by their optionlist value, and not as a refName. The > displayName is stored with the refName for this reason. If we > want to update the UI to store the refNames, then you could > get the Display Name in search results. However, I am not > sure what chaos that would cause in the HTML DOM (i.e., > having the value be a URI, and not an alphanumeric string). > Yura can speak to this. > > I seem to remember Susan asking about this as well. > > Patrick > > > -----Original Message----- > > From: Work [mailto:work-bounces@lists.collectionspace.org] > On Behalf > > Of Jesse Martinez > > Sent: Wednesday, October 24, 2012 10:23 AM > > To: CollectionSpace Work list; CollectionSpace Talk List > > Subject: [Work] setting a controlled list field as a summary field > > > > When I set a field that is a controlled list as a summary > field I get > > the id string of the controlled list term instead of the > text string. > > In other words, "needsnowork" is the summary value shown in > the UI and > > not the more readable form "Needs no work" string. > > This is taken from the app layer config for the procedure I'm > > developing: <option id="needsnowork">Needs no work</option>. > > > > Is there any way to have the actual text string and not the > id string > > display in the UI? > > FWIW, I'm using v2.6 code. > > > > Thanks, > > > > - Jesse > > > > _______________________________________________ > > Work mailing list > > Work@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/work_lists.c > > ollectionspace.org > > > > > _______________________________________________ > Work mailing list > Work@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/work_lists.c > ollectionspace.org >

Hi, In order to configure each drop down we use 2 lists of values: option names (displayed by UI) and options list (actual values saved). From UI's perspective they can be identical and the drop-down doesn't really care which one is which. Currently the renderer that we use in the framework requires those 2 groups to be separate since we can not assume that the values and names are always the same. So in case we made that assumption (and the app layer was sending just one unified list), I would need to update the renderer slightly to populate those 2 distinct lists on our side from a single list from the app layer. Yura On 2012-10-24, at 2:15 PM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: > Did a quick trial on at least one play site (w3schools), and it had no > problem with a uri with display name as the option value attribute value. > > Yura? What's the reason why we use the shorter form? It is certainly > simpler, including on input. But it does have this drawback. > > Patrick > >> -----Original Message----- >> From: Work [mailto:work-bounces@lists.collectionspace.org] On >> Behalf Of Patrick Schmitz >> Sent: Wednesday, October 24, 2012 11:12 AM >> To: 'Jesse Martinez'; 'CollectionSpace Work list'; >> 'CollectionSpace Talk List' >> Subject: Re: [Work] setting a controlled list field as a summary field >> >> Currently, the UI is saving the static termList references >> only by their optionlist value, and not as a refName. The >> displayName is stored with the refName for this reason. If we >> want to update the UI to store the refNames, then you could >> get the Display Name in search results. However, I am not >> sure what chaos that would cause in the HTML DOM (i.e., >> having the value be a URI, and not an alphanumeric string). >> Yura can speak to this. >> >> I seem to remember Susan asking about this as well. >> >> Patrick >> >>> -----Original Message----- >>> From: Work [mailto:work-bounces@lists.collectionspace.org] >> On Behalf >>> Of Jesse Martinez >>> Sent: Wednesday, October 24, 2012 10:23 AM >>> To: CollectionSpace Work list; CollectionSpace Talk List >>> Subject: [Work] setting a controlled list field as a summary field >>> >>> When I set a field that is a controlled list as a summary >> field I get >>> the id string of the controlled list term instead of the >> text string. >>> In other words, "needsnowork" is the summary value shown in >> the UI and >>> not the more readable form "Needs no work" string. >>> This is taken from the app layer config for the procedure I'm >>> developing: <option id="needsnowork">Needs no work</option>. >>> >>> Is there any way to have the actual text string and not the >> id string >>> display in the UI? >>> FWIW, I'm using v2.6 code. >>> >>> Thanks, >>> >>> - Jesse >>> >>> _______________________________________________ >>> Work mailing list >>> Work@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/work_lists.c >>> ollectionspace.org >>> >> >> >> _______________________________________________ >> Work mailing list >> Work@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/work_lists.c >> ollectionspace.org >> > > > _______________________________________________ > Work mailing list > Work@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org

I think this would be incredibly useful. And hopefully this can be back ported to v2.6. - Jesse On Wed, Oct 24, 2012 at 2:38 PM, Zenevich, Yura <yzenevich@ocadu.ca> wrote: > Hi, > > In order to configure each drop down we use 2 lists of values: option names (displayed by UI) and options list (actual values saved). From UI's perspective they can be identical and the drop-down doesn't really care which one is which. > > Currently the renderer that we use in the framework requires those 2 groups to be separate since we can not assume that the values and names are always the same. So in case we made that assumption (and the app layer was sending just one unified list), I would need to update the renderer slightly to populate those 2 distinct lists on our side from a single list from the app layer. > > Yura > > On 2012-10-24, at 2:15 PM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: > >> Did a quick trial on at least one play site (w3schools), and it had no >> problem with a uri with display name as the option value attribute value. >> >> Yura? What's the reason why we use the shorter form? It is certainly >> simpler, including on input. But it does have this drawback. >> >> Patrick >> >>> -----Original Message----- >>> From: Work [mailto:work-bounces@lists.collectionspace.org] On >>> Behalf Of Patrick Schmitz >>> Sent: Wednesday, October 24, 2012 11:12 AM >>> To: 'Jesse Martinez'; 'CollectionSpace Work list'; >>> 'CollectionSpace Talk List' >>> Subject: Re: [Work] setting a controlled list field as a summary field >>> >>> Currently, the UI is saving the static termList references >>> only by their optionlist value, and not as a refName. The >>> displayName is stored with the refName for this reason. If we >>> want to update the UI to store the refNames, then you could >>> get the Display Name in search results. However, I am not >>> sure what chaos that would cause in the HTML DOM (i.e., >>> having the value be a URI, and not an alphanumeric string). >>> Yura can speak to this. >>> >>> I seem to remember Susan asking about this as well. >>> >>> Patrick >>> >>>> -----Original Message----- >>>> From: Work [mailto:work-bounces@lists.collectionspace.org] >>> On Behalf >>>> Of Jesse Martinez >>>> Sent: Wednesday, October 24, 2012 10:23 AM >>>> To: CollectionSpace Work list; CollectionSpace Talk List >>>> Subject: [Work] setting a controlled list field as a summary field >>>> >>>> When I set a field that is a controlled list as a summary >>> field I get >>>> the id string of the controlled list term instead of the >>> text string. >>>> In other words, "needsnowork" is the summary value shown in >>> the UI and >>>> not the more readable form "Needs no work" string. >>>> This is taken from the app layer config for the procedure I'm >>>> developing: <option id="needsnowork">Needs no work</option>. >>>> >>>> Is there any way to have the actual text string and not the >>> id string >>>> display in the UI? >>>> FWIW, I'm using v2.6 code. >>>> >>>> Thanks, >>>> >>>> - Jesse >>>> >>>> _______________________________________________ >>>> Work mailing list >>>> Work@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/work_lists.c >>>> ollectionspace.org >>>> >>> >>> >>> _______________________________________________ >>> Work mailing list >>> Work@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/work_lists.c >>> ollectionspace.org >>> >> >> >> _______________________________________________ >> Work mailing list >> Work@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >

Hi Yura, hi Jesse - I'm just getting a few moments to think about this. A couple of issues come to mind. Particularly, I can think of several cases where the option names and values are NOT the same, or shouldn't be. One, the case of a standards-based list like countries (ISO-3166) that specifies an abbreviation to save and pass between systems, in addition to a (human-readable) display name. Two, existing deployments that already have a database full of stored values that differ from the displayed values, and therefore can't easily change. Also, at some point we should make the display values internationalizable, without forcing deployers to edit the options list in the config files. (It's easy to make major mistakes mucking around in those lists!) One way to do that would be to replace the display value with a message key so that translations could be defined in core-messages.properties or in a core-messages.properties-overlay file. It wouldn't make sense to use that message key as the stored value. Patrick's suggestion about converting static termList values to a refName format would also allow deployers to add translations -- if we were to extend the non-preferred terms mechanism beyond authority terms. (But that, too, would force current deployments to modify existing data.) Rick On Oct 24, 2012, at 2:37 PM, Jesse Martinez wrote: > I think this would be incredibly useful. And hopefully this can be > back ported to v2.6. > > - Jesse > > On Wed, Oct 24, 2012 at 2:38 PM, Zenevich, Yura <yzenevich@ocadu.ca> wrote: >> Hi, >> >> In order to configure each drop down we use 2 lists of values: option names (displayed by UI) and options list (actual values saved). From UI's perspective they can be identical and the drop-down doesn't really care which one is which. >> >> Currently the renderer that we use in the framework requires those 2 groups to be separate since we can not assume that the values and names are always the same. So in case we made that assumption (and the app layer was sending just one unified list), I would need to update the renderer slightly to populate those 2 distinct lists on our side from a single list from the app layer. >> >> Yura >> >> On 2012-10-24, at 2:15 PM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: >> >>> Did a quick trial on at least one play site (w3schools), and it had no >>> problem with a uri with display name as the option value attribute value. >>> >>> Yura? What's the reason why we use the shorter form? It is certainly >>> simpler, including on input. But it does have this drawback. >>> >>> Patrick >>> >>>> -----Original Message----- >>>> From: Work [mailto:work-bounces@lists.collectionspace.org] On >>>> Behalf Of Patrick Schmitz >>>> Sent: Wednesday, October 24, 2012 11:12 AM >>>> To: 'Jesse Martinez'; 'CollectionSpace Work list'; >>>> 'CollectionSpace Talk List' >>>> Subject: Re: [Work] setting a controlled list field as a summary field >>>> >>>> Currently, the UI is saving the static termList references >>>> only by their optionlist value, and not as a refName. The >>>> displayName is stored with the refName for this reason. If we >>>> want to update the UI to store the refNames, then you could >>>> get the Display Name in search results. However, I am not >>>> sure what chaos that would cause in the HTML DOM (i.e., >>>> having the value be a URI, and not an alphanumeric string). >>>> Yura can speak to this. >>>> >>>> I seem to remember Susan asking about this as well. >>>> >>>> Patrick >>>> >>>>> -----Original Message----- >>>>> From: Work [mailto:work-bounces@lists.collectionspace.org] >>>> On Behalf >>>>> Of Jesse Martinez >>>>> Sent: Wednesday, October 24, 2012 10:23 AM >>>>> To: CollectionSpace Work list; CollectionSpace Talk List >>>>> Subject: [Work] setting a controlled list field as a summary field >>>>> >>>>> When I set a field that is a controlled list as a summary >>>> field I get >>>>> the id string of the controlled list term instead of the >>>> text string. >>>>> In other words, "needsnowork" is the summary value shown in >>>> the UI and >>>>> not the more readable form "Needs no work" string. >>>>> This is taken from the app layer config for the procedure I'm >>>>> developing: <option id="needsnowork">Needs no work</option>. >>>>> >>>>> Is there any way to have the actual text string and not the >>>> id string >>>>> display in the UI? >>>>> FWIW, I'm using v2.6 code. >>>>> >>>>> Thanks, >>>>> >>>>> - Jesse >>>>> >>>>> _______________________________________________ >>>>> Work mailing list >>>>> Work@lists.collectionspace.org >>>>> http://lists.collectionspace.org/mailman/listinfo/work_lists.c >>>>> ollectionspace.org >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Work mailing list >>>> Work@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/work_lists.c >>>> ollectionspace.org >>>> >>> >>> >>> _______________________________________________ >>> Work mailing list >>> Work@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >> > > _______________________________________________ > Work mailing list > Work@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org