The docs say NO<http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results>, but there appears to be a way of merging several fields together in to a temporary field, which then acts as the sole summary field for search results. (This summary designation is based on the values listed within the "mini=summary" tag used in the application configuration.) Has anybody used this in their deployment? I ask because I can't seem find a working example. CollectionObject uses two fields, titleGroup/title and objectName, to act as summary fields where if the title field doesn't have a value then objectName is used as the summary value in the search results listing.<https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79>But I haven't seen it work in expected. I'm looking to duplicate what CollectionObject attempts to do -- two fields act as the summary value in search results where if the first (rank=1) field is empty then the second (rank=2) field gets used. Thanks, - Jesse

Jesse, This (that is, object name if no title) definitely used to work in early versions (of, say, PAHMA). I haven't checked lately though. I'm not sure about concatenating two fields, which I also requested way back. Susan > The docs say > NO<http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results>, > but there appears to be a way of merging several fields together in to a > temporary field, which then acts as the sole summary field for search > results. (This summary designation is based on the values listed within > the > "mini=summary" tag used in the application configuration.) > > Has anybody used this in their deployment? I ask because I can't seem find > a working example. CollectionObject uses two fields, titleGroup/title and > objectName, to act as summary fields where if the title field doesn't have > a value then objectName is used as the summary value in the search results > listing.<https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79>But > I haven't seen it work in expected. I'm looking to duplicate what > CollectionObject attempts to do -- two fields act as the summary value in > search results where if the first (rank=1) field is empty then the second > (rank=2) field gets used. > > Thanks, > > - Jesse > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

<field id="nametitle" mini="summary,search,list,relate"

  <selector>object-identification-object-nametitle</selector>

  <merges>

    <merge id="title" rank="1"/>

    <merge id="objectName" rank="2"/>

  </merges>

</field>

I am pretty sure this is logic in the app layer, and should work. However, it imposes some constraints: · You can no longer sort on the summary column (app layer and services are not coordinated enough to manage the multiple sort, and am not sure it would work as expected anyway). · It may work in some contexts and not in others. The logic I think I remember seeing may only exist in one code path (e.g., search results), and not in others (e.g., related objects, or related procedures). Worst case would be that it is specific to CollectionObject – I hope not. Here’s the config that I think controls it: <field id="nametitle" mini="summary,search,list,relate" exists-in-services="false"> <selector>object-identification-object-nametitle</selector> <merges> <merge id="title" rank="1"/> <merge id="objectName" rank="2"/> </merges> </field> Does this not work elsewhere? There is only one other example I found, in acquisition, however it is not used in list results. Patrick *From:* Talk [mailto:talk-bounces@lists.collectionspace.org] *On Behalf Of *Jesse Martinez *Sent:* Tuesday, April 09, 2013 10:09 AM *To:* CollectionSpace Talk List *Subject:* [Talk] is it possible to have more than one field act as a summary value for a record? The docs say NO<http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results>, but there appears to be a way of merging several fields together in to a temporary field, which then acts as the sole summary field for search results. (This summary designation is based on the values listed within the "mini=summary" tag used in the application configuration.) Has anybody used this in their deployment? I ask because I can't seem find a working example. CollectionObject uses two fields, titleGroup/title and objectName, to act as summary fields where if the title field doesn't have a value then objectName is used as the summary value in the search results listing.<https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79>But I haven't seen it work in expected. I'm looking to duplicate what CollectionObject attempts to do -- two fields act as the summary value in search results where if the first (rank=1) field is empty then the second (rank=2) field gets used. Thanks, - Jesse

I thought so too? Here's what I see on Demo: title=MY TITLE objectName=MY NAME search results summary=MY NAME title= objectName=MY NAME search results summary=MY NAME title=MY TITLE objectName= search results summary= {empty} - Jesse On Tue, Apr 9, 2013 at 1:16 PM, <sstone@socrates.berkeley.edu> wrote: > Jesse, > > This (that is, object name if no title) definitely used to work in early > versions (of, say, PAHMA). I haven't checked lately though. I'm not sure > about concatenating two fields, which I also requested way back. > > Susan > > > The docs say > > NO< > http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results > >, > > but there appears to be a way of merging several fields together in to a > > temporary field, which then acts as the sole summary field for search > > results. (This summary designation is based on the values listed within > > the > > "mini=summary" tag used in the application configuration.) > > > > Has anybody used this in their deployment? I ask because I can't seem > find > > a working example. CollectionObject uses two fields, titleGroup/title and > > objectName, to act as summary fields where if the title field doesn't > have > > a value then objectName is used as the summary value in the search > results > > listing.< > https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79 > >But > > I haven't seen it work in expected. I'm looking to duplicate what > > CollectionObject attempts to do -- two fields act as the summary value in > > search results where if the first (rank=1) field is empty then the second > > (rank=2) field gets used. > > > > Thanks, > > > > - Jesse > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > >

 <field id="nametitle" mini="summary,search,list,relate"

   <selector>object-identification-object-nametitle</selector>

   <merges>

     <merge id="title" rank="1"/>

     <merge id="objectName" rank="2"/>

   </merges>

 </field>

Thanks, Patrick. Yep, that's the app layer config that controls the merged summary fields, fwiu. It may be an OK trade off, for me at least, so not have sort on summary fields on search results. Hmm, I'd like to see it work in all contexts including related things, but I could live with only search results having this merged behavior. I'm attempting to use the same configuration on a custom procedure and I'm getting results akin to what I've found on CollectionObject: even with the merged fields I can only see the objectName value and not the title value. That is, rank=2 takes precedence. On Tue, Apr 9, 2013 at 1:28 PM, Patrick Schmitz <pschmitz@berkeley.edu>wrote: > I am pretty sure this is logic in the app layer, and should work. However, > it imposes some constraints: > > · You can no longer sort on the summary column (app layer and > services are not coordinated enough to manage the multiple sort, and am not > sure it would work as expected anyway). > > · It may work in some contexts and not in others. The logic I > think I remember seeing may only exist in one code path (e.g., search > results), and not in others (e.g., related objects, or related procedures). > > > > Worst case would be that it is specific to CollectionObject – I hope not. > > > > Here’s the config that I think controls it: > > > > <field id="nametitle" mini="summary,search,list,relate" > exists-in-services="false"> > > <selector>object-identification-object-nametitle</selector> > > <merges> > > <merge id="title" rank="1"/> > > <merge id="objectName" rank="2"/> > > </merges> > > </field> > > > > Does this not work elsewhere? There is only one other example I found, in > acquisition, however it is not used in list results. > > > > Patrick > > > > *From:* Talk [mailto:talk-bounces@lists.collectionspace.org] *On Behalf > Of *Jesse Martinez > *Sent:* Tuesday, April 09, 2013 10:09 AM > *To:* CollectionSpace Talk List > *Subject:* [Talk] is it possible to have more than one field act as a > summary value for a record? > > > > The docs say NO<http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results>, > but there appears to be a way of merging several fields together in to a > temporary field, which then acts as the sole summary field for search > results. (This summary designation is based on the values listed within the > "mini=summary" tag used in the application configuration.) > > > > Has anybody used this in their deployment? I ask because I can't seem find > a working example. CollectionObject uses two fields, titleGroup/title and > objectName, to act as summary fields where if the title field doesn't have > a value then objectName is used as the summary value in the search results > listing.<https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79>But I haven't seen it work in expected. I'm looking to duplicate what > CollectionObject attempts to do -- two fields act as the summary value in > search results where if the first (rank=1) field is empty then the second > (rank=2) field gets used. > > > > Thanks, > > > > - Jesse >

 <field id="nametitle" mini="summary,search,list,relate"

   <selector>object-identification-object-nametitle</selector>

   <merges>

     <merge id="title" rank="1"/>

     <merge id="objectName" rank="2"/>

   </merges>

 </field>

Hi Jesse, Are the fields you're trying to "merge" from different schemas? If so, PAHMA-469 <http://issues.collectionspace.org/browse/PAHMA-469> and CSPACE-5436 <http://issues.collectionspace.org/browse/CSPACE-5436> would apply. I think we're finding at UCB that the app layer merge is not ideal for the reasons that Patrick descibes. To handle this, we've started to store this kind of computed value in a separate field that the services layer can see. There are a couple ways to do this. As one option, we have a UI component that can set the value of a field based on values in other fields. The other option is to use a nuxeo event handler, which would execute on the server when a document is saved, calcuating and storing a merged value. Ray On Tue, Apr 9, 2013 at 10:55 AM, Jesse Martinez <mjesse@gmail.com> wrote: > Thanks, Patrick. > > Yep, that's the app layer config that controls the merged summary fields, > fwiu. It may be an OK trade off, for me at least, so not have sort on > summary fields on search results. Hmm, I'd like to see it work in all > contexts including related things, but I could live with only search > results having this merged behavior. > I'm attempting to use the same configuration on a custom procedure and I'm > getting results akin to what I've found on CollectionObject: even with the > merged fields I can only see the objectName value and not the title value. > That is, rank=2 takes precedence. > > > On Tue, Apr 9, 2013 at 1:28 PM, Patrick Schmitz <pschmitz@berkeley.edu>wrote: > >> I am pretty sure this is logic in the app layer, and should work. >> However, it imposes some constraints: >> >> · You can no longer sort on the summary column (app layer and >> services are not coordinated enough to manage the multiple sort, and am not >> sure it would work as expected anyway). >> >> · It may work in some contexts and not in others. The logic I >> think I remember seeing may only exist in one code path (e.g., search >> results), and not in others (e.g., related objects, or related procedures). >> >> >> >> Worst case would be that it is specific to CollectionObject – I hope not. >> >> >> >> Here’s the config that I think controls it: >> >> >> >> <field id="nametitle" mini="summary,search,list,relate" >> exists-in-services="false"> >> >> <selector>object-identification-object-nametitle</selector> >> >> <merges> >> >> <merge id="title" rank="1"/> >> >> <merge id="objectName" rank="2"/> >> >> </merges> >> >> </field> >> >> >> >> Does this not work elsewhere? There is only one other example I found, in >> acquisition, however it is not used in list results. >> >> >> >> Patrick >> >> >> >> *From:* Talk [mailto:talk-bounces@lists.collectionspace.org] *On Behalf >> Of *Jesse Martinez >> *Sent:* Tuesday, April 09, 2013 10:09 AM >> *To:* CollectionSpace Talk List >> *Subject:* [Talk] is it possible to have more than one field act as a >> summary value for a record? >> >> >> >> The docs say NO<http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results>, >> but there appears to be a way of merging several fields together in to a >> temporary field, which then acts as the sole summary field for search >> results. (This summary designation is based on the values listed within the >> "mini=summary" tag used in the application configuration.) >> >> >> >> Has anybody used this in their deployment? I ask because I can't seem >> find a working example. CollectionObject uses two fields, >> titleGroup/title and objectName, to act as summary fields where if the >> title field doesn't have a value then objectName is used as the summary >> value in the search results listing.<https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79>But I haven't seen it work in expected. I'm looking to duplicate what >> CollectionObject attempts to do -- two fields act as the summary value in >> search results where if the first (rank=1) field is empty then the second >> (rank=2) field gets used. >> >> >> >> Thanks, >> >> >> >> - Jesse >> > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

 <field id="nametitle" mini="summary,search,list,relate"

   <selector>object-identification-object-nametitle</selector>

   <merges>

     <merge id="title" rank="1"/>

     <merge id="objectName" rank="2"/>

   </merges>

 </field>

Hi Ray, My merged fields are in the same common schema, so I don't have the same issue as the Jiras you listed. Please share how you're setting up a UI component that pulls the value of other fields in! And how would this be different than the nuxeo event handler? Is this the case where you'd be pulling in values/data from fields outside the record? Like in calculating location within Cataloging? To be honest, I'll be needing to do both cases (local values and outside values) for my custom procedure. On Tue, Apr 9, 2013 at 2:15 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Jesse, > Are the fields you're trying to "merge" from different schemas? If so, > PAHMA-469 <http://issues.collectionspace.org/browse/PAHMA-469> and > CSPACE-5436 <http://issues.collectionspace.org/browse/CSPACE-5436> would > apply. > > I think we're finding at UCB that the app layer merge is not ideal for the > reasons that Patrick descibes. To handle this, we've started to store this > kind of computed value in a separate field that the services layer can see. > There are a couple ways to do this. As one option, we have a UI component > that can set the value of a field based on values in other fields. The > other option is to use a nuxeo event handler, which would execute on the > server when a document is saved, calcuating and storing a merged value. > > Ray > > > On Tue, Apr 9, 2013 at 10:55 AM, Jesse Martinez <mjesse@gmail.com> wrote: > >> Thanks, Patrick. >> >> Yep, that's the app layer config that controls the merged summary fields, >> fwiu. It may be an OK trade off, for me at least, so not have sort on >> summary fields on search results. Hmm, I'd like to see it work in all >> contexts including related things, but I could live with only search >> results having this merged behavior. >> I'm attempting to use the same configuration on a custom procedure and >> I'm getting results akin to what I've found on CollectionObject: even with >> the merged fields I can only see the objectName value and not the title >> value. That is, rank=2 takes precedence. >> >> >> On Tue, Apr 9, 2013 at 1:28 PM, Patrick Schmitz <pschmitz@berkeley.edu>wrote: >> >>> I am pretty sure this is logic in the app layer, and should work. >>> However, it imposes some constraints: >>> >>> · You can no longer sort on the summary column (app layer and >>> services are not coordinated enough to manage the multiple sort, and am not >>> sure it would work as expected anyway). >>> >>> · It may work in some contexts and not in others. The logic I >>> think I remember seeing may only exist in one code path (e.g., search >>> results), and not in others (e.g., related objects, or related procedures). >>> >>> >>> >>> Worst case would be that it is specific to CollectionObject – I hope >>> not. >>> >>> >>> >>> Here’s the config that I think controls it: >>> >>> >>> >>> <field id="nametitle" mini="summary,search,list,relate" >>> exists-in-services="false"> >>> >>> <selector>object-identification-object-nametitle</selector> >>> >>> <merges> >>> >>> <merge id="title" rank="1"/> >>> >>> <merge id="objectName" rank="2"/> >>> >>> </merges> >>> >>> </field> >>> >>> >>> >>> Does this not work elsewhere? There is only one other example I found, >>> in acquisition, however it is not used in list results. >>> >>> >>> >>> Patrick >>> >>> >>> >>> *From:* Talk [mailto:talk-bounces@lists.collectionspace.org] *On Behalf >>> Of *Jesse Martinez >>> *Sent:* Tuesday, April 09, 2013 10:09 AM >>> *To:* CollectionSpace Talk List >>> *Subject:* [Talk] is it possible to have more than one field act as a >>> summary value for a record? >>> >>> >>> >>> The docs say NO<http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results>, >>> but there appears to be a way of merging several fields together in to a >>> temporary field, which then acts as the sole summary field for search >>> results. (This summary designation is based on the values listed within the >>> "mini=summary" tag used in the application configuration.) >>> >>> >>> >>> Has anybody used this in their deployment? I ask because I can't seem >>> find a working example. CollectionObject uses two fields, >>> titleGroup/title and objectName, to act as summary fields where if the >>> title field doesn't have a value then objectName is used as the summary >>> value in the search results listing.<https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79>But I haven't seen it work in expected. I'm looking to duplicate what >>> CollectionObject attempts to do -- two fields act as the summary value in >>> search results where if the first (rank=1) field is empty then the second >>> (rank=2) field gets used. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> - Jesse >>> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >

Hmmm. Looked at the code, and it seems to be right, but we would need to step through it to figure whether it is getting called the right way at the right times. When time permits… Patrick *From:* Talk [mailto:talk-bounces@lists.collectionspace.org] *On Behalf Of *Jesse Martinez *Sent:* Tuesday, April 09, 2013 10:31 AM *To:* Susan Stone *Cc:* CollectionSpace Talk List *Subject:* Re: [Talk] is it possible to have more than one field act as a summary value for a record? I thought so too? Here's what I see on Demo: title=MY TITLE objectName=MY NAME search results summary=MY NAME title= objectName=MY NAME search results summary=MY NAME title=MY TITLE objectName= search results summary= {empty} - Jesse On Tue, Apr 9, 2013 at 1:16 PM, <sstone@socrates.berkeley.edu> wrote: Jesse, This (that is, object name if no title) definitely used to work in early versions (of, say, PAHMA). I haven't checked lately though. I'm not sure about concatenating two fields, which I also requested way back. Susan > The docs say > NO< http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results >, > but there appears to be a way of merging several fields together in to a > temporary field, which then acts as the sole summary field for search > results. (This summary designation is based on the values listed within > the > "mini=summary" tag used in the application configuration.) > > Has anybody used this in their deployment? I ask because I can't seem find > a working example. CollectionObject uses two fields, titleGroup/title and > objectName, to act as summary fields where if the title field doesn't have > a value then objectName is used as the summary value in the search results > listing.< https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79 >But > I haven't seen it work in expected. I'm looking to duplicate what > CollectionObject attempts to do -- two fields act as the summary value in > search results where if the first (rank=1) field is empty then the second > (rank=2) field gets used. > > Thanks, > > - Jesse > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

 <field id="nametitle" mini="summary,search,list,relate"

   <selector>object-identification-object-nametitle</selector>

   <merges>

     <merge id="title" rank="1"/>

     <merge id="objectName" rank="2"/>

   </merges>

 </field>

Hi Jesse, The computed field component is here: https://github.com/cspace-deployment/ui/blob/v3.2/src/main/webapp/defaults/js/ComputedField.js There are some associated demands: https://github.com/cspace-deployment/ui/blob/v3.2/src/main/webapp/defaults/js/Demands.js#L1897 Some examples of app layer config to use the component: https://github.com/cspace-deployment/application/blob/pahma_3.2/tomcat-main/src/main/resources/tenants/pahma/local-collectionobject.xml#L183 https://github.com/cspace-deployment/application/blob/pahma_3.2/tomcat-main/src/main/resources/defaults/anthropology-procedure-movement.xml#L13 https://github.com/cspace-deployment/application/blob/ucjeps_3.2/tomcat-main/src/main/resources/tenants/ucjeps/local-collectionobject.xml#L154 We've also built up a small library of event handlers that might be helpful as examples: https://github.com/cspace-deployment/services/tree/botgarden_3.2/3rdparty/nuxeo/nuxeo-platform-botgarden/src/main/java/org/collectionspace/services/nuxeo/extension/botgarden Here are some differences between using the UI component vs. a Nuxeo event handler: UI Component - Only runs when documents are updated through the UI - Can only access fields from the current document (also, there's a current limitation that all the source fields must be top-level fields if the target field is top-level, or all the source fields must be in the same repeating group as the target field, if the target field is in a repeating group). - Computation function is written in javascript - May be interactive (user may see values update as they edit, without having to save) Event Handler - Runs when documents are updated through the UI or REST API (including imports) - Can access fields from the current document, or any other document - Computation function is written in Java - Not interactive (user only sees new values after saving) Let me know if you need any more info. Thanks, Ray On Tue, Apr 9, 2013 at 11:27 AM, Jesse Martinez <mjesse@gmail.com> wrote: > Hi Ray, > > My merged fields are in the same common schema, so I don't have the same > issue as the Jiras you listed. > > Please share how you're setting up a UI component that pulls the value of > other fields in! And how would this be different than the nuxeo event > handler? Is this the case where you'd be pulling in values/data from fields > outside the record? Like in calculating location within Cataloging? To be > honest, I'll be needing to do both cases (local values and outside values) > for my custom procedure. > > > On Tue, Apr 9, 2013 at 2:15 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> Hi Jesse, >> Are the fields you're trying to "merge" from different schemas? If so, >> PAHMA-469 <http://issues.collectionspace.org/browse/PAHMA-469> and >> CSPACE-5436 <http://issues.collectionspace.org/browse/CSPACE-5436> would >> apply. >> >> I think we're finding at UCB that the app layer merge is not ideal for >> the reasons that Patrick descibes. To handle this, we've started to store >> this kind of computed value in a separate field that the services layer can >> see. There are a couple ways to do this. As one option, we have a UI >> component that can set the value of a field based on values in other >> fields. The other option is to use a nuxeo event handler, which would >> execute on the server when a document is saved, calcuating and storing a >> merged value. >> >> Ray >> >> >> On Tue, Apr 9, 2013 at 10:55 AM, Jesse Martinez <mjesse@gmail.com> wrote: >> >>> Thanks, Patrick. >>> >>> Yep, that's the app layer config that controls the merged summary >>> fields, fwiu. It may be an OK trade off, for me at least, so not have sort >>> on summary fields on search results. Hmm, I'd like to see it work in all >>> contexts including related things, but I could live with only search >>> results having this merged behavior. >>> I'm attempting to use the same configuration on a custom procedure and >>> I'm getting results akin to what I've found on CollectionObject: even with >>> the merged fields I can only see the objectName value and not the title >>> value. That is, rank=2 takes precedence. >>> >>> >>> On Tue, Apr 9, 2013 at 1:28 PM, Patrick Schmitz <pschmitz@berkeley.edu>wrote: >>> >>>> I am pretty sure this is logic in the app layer, and should work. >>>> However, it imposes some constraints: >>>> >>>> · You can no longer sort on the summary column (app layer and >>>> services are not coordinated enough to manage the multiple sort, and am not >>>> sure it would work as expected anyway). >>>> >>>> · It may work in some contexts and not in others. The logic I >>>> think I remember seeing may only exist in one code path (e.g., search >>>> results), and not in others (e.g., related objects, or related procedures). >>>> >>>> >>>> >>>> Worst case would be that it is specific to CollectionObject – I hope >>>> not. >>>> >>>> >>>> >>>> Here’s the config that I think controls it: >>>> >>>> >>>> >>>> <field id="nametitle" mini="summary,search,list,relate" >>>> exists-in-services="false"> >>>> >>>> <selector>object-identification-object-nametitle</selector> >>>> >>>> <merges> >>>> >>>> <merge id="title" rank="1"/> >>>> >>>> <merge id="objectName" rank="2"/> >>>> >>>> </merges> >>>> >>>> </field> >>>> >>>> >>>> >>>> Does this not work elsewhere? There is only one other example I found, >>>> in acquisition, however it is not used in list results. >>>> >>>> >>>> >>>> Patrick >>>> >>>> >>>> >>>> *From:* Talk [mailto:talk-bounces@lists.collectionspace.org] *On >>>> Behalf Of *Jesse Martinez >>>> *Sent:* Tuesday, April 09, 2013 10:09 AM >>>> *To:* CollectionSpace Talk List >>>> *Subject:* [Talk] is it possible to have more than one field act as a >>>> summary value for a record? >>>> >>>> >>>> >>>> The docs say NO<http://wiki.collectionspace.org/display/DOC/How+to+change+the+columns+in+the+search+results>, >>>> but there appears to be a way of merging several fields together in to a >>>> temporary field, which then acts as the sole summary field for search >>>> results. (This summary designation is based on the values listed within the >>>> "mini=summary" tag used in the application configuration.) >>>> >>>> >>>> >>>> Has anybody used this in their deployment? I ask because I can't seem >>>> find a working example. CollectionObject uses two fields, >>>> titleGroup/title and objectName, to act as summary fields where if the >>>> title field doesn't have a value then objectName is used as the summary >>>> value in the search results listing.<https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-collectionobject.xml#L73-L79>But I haven't seen it work in expected. I'm looking to duplicate what >>>> CollectionObject attempts to do -- two fields act as the summary value in >>>> search results where if the first (rank=1) field is empty then the second >>>> (rank=2) field gets used. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> - Jesse >>>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >> >

On Tue, Apr 9, 2013 at 12:34 PM, Ray Lee <rhlee@berkeley.edu> wrote: > We've also built up a small library of event handlers that might be helpful > as examples: > > https://github.com/cspace-deployment/services/tree/botgarden_3.2/3rdparty/nuxeo/nuxeo-platform-botgarden/src/main/java/org/collectionspace/services/nuxeo/extension/botgarden That's a very useful library - great models to follow - BTW. And two more event handlers ship 'out of the box' with CollectionSpace: https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener (/3rdparty/nuxeo/nuxeo-platform-listener is now the suggested home within the Services build tree for Nuxeo event listeners, if you're looking for a directory in which to add your own custom event handlers.) Aron P.S. Ray's UI component for maintaining data in computed fields was created under the aegis of http://issues.collectionspace.org/browse/PAHMA-244 > > Here are some differences between using the UI component vs. a Nuxeo event > handler: > > UI Component > > Only runs when documents are updated through the UI > Can only access fields from the current document (also, there's a current > limitation that all the source fields must be top-level fields if the target > field is top-level, or all the source fields must be in the same repeating > group as the target field, if the target field is in a repeating group). > Computation function is written in javascript > May be interactive (user may see values update as they edit, without having > to save) > > Event Handler > > Runs when documents are updated through the UI or REST API (including > imports) > Can access fields from the current document, or any other document > Computation function is written in Java > Not interactive (user only sees new values after saving) > > Let me know if you need any more info. > > Thanks, > Ray > > > > On Tue, Apr 9, 2013 at 11:27 AM, Jesse Martinez <mjesse@gmail.com> wrote: >> >> Hi Ray, >> >> My merged fields are in the same common schema, so I don't have the same >> issue as the Jiras you listed. >> >> Please share how you're setting up a UI component that pulls the value of >> other fields in! And how would this be different than the nuxeo event >> handler? Is this the case where you'd be pulling in values/data from fields >> outside the record? Like in calculating location within Cataloging? To be >> honest, I'll be needing to do both cases (local values and outside values) >> for my custom procedure.