I forgot, there are some app layer changes necessary to make the computed field UI component configuration work. I believe they consist of these commits: https://github.com/cspace-deployment/application/commit/f5c6810 https://github.com/cspace-deployment/application/commit/c6657e2 https://github.com/cspace-deployment/application/commit/91d42fd https://github.com/cspace-deployment/application/commit/e71d5c3 https://github.com/cspace-deployment/application/commit/a5df050 Ray On Tue, Apr 9, 2013 at 12:45 PM, Aron Roberts <aron@socrates.berkeley.edu>wrote: > 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. >

- 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)

- 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)

 <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 for this, Ray. Quick questions: where do the functions listed in the ui-func attribute get defined? And are UI component/Event Handler fields always read-only? (I assume they should be, but curious about any cases where it wouldn't.) - Jesse On Tue, Apr 9, 2013 at 3:34 PM, Ray Lee <rhlee@berkeley.edu> wrote: > 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 >>>> >>>> >>> >> >

- 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)

- 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)

 <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 functions in the ui-func attribute can be defined in any js file in the UI, as long as it's included via <script> tag in record.html (and advancedsearch.html, if you're using computed fields on advanced search). The functions referenced in the above examples are here: https://github.com/cspace-deployment/ui/blob/pahma_3.2/src/main/webapp/tenants/pahma/js/pahma.js https://github.com/cspace-deployment/ui/blob/ucjeps_3.2/src/main/webapp/defaults/js/Georef.js I can imagine a scenario where you might want to allow the user to enter a value, and compute something if they leave it blank, but the computed field component isn't really equipped to deal with that right now. So for now at least, I think computed fields should always be read-only. Ray On Tue, Apr 9, 2013 at 1:42 PM, Jesse Martinez <mjesse@gmail.com> wrote: > Thanks for this, Ray. Quick questions: where do the functions listed in > the ui-func attribute get defined? And are UI component/Event Handler > fields always read-only? (I assume they should be, but curious about any > cases where it wouldn't.) > > - Jesse > > > On Tue, Apr 9, 2013 at 3:34 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> 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 >>>>> >>>>> >>>> >>> >> >

- 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)

- 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)

 <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>

Thank you for your help, Ray; the app/ui component code worked well. (BTW, there are also some files in cspi-schema and cspi-webui that required some updates as well.) - Jesse On Tue, Apr 9, 2013 at 6:51 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Jesse, > The functions in the ui-func attribute can be defined in any js file in > the UI, as long as it's included via <script> tag in record.html (and > advancedsearch.html, if you're using computed fields on advanced search). > The functions referenced in the above examples are here: > > > https://github.com/cspace-deployment/ui/blob/pahma_3.2/src/main/webapp/tenants/pahma/js/pahma.js > > https://github.com/cspace-deployment/ui/blob/ucjeps_3.2/src/main/webapp/defaults/js/Georef.js > > I can imagine a scenario where you might want to allow the user to enter a > value, and compute something if they leave it blank, but the computed field > component isn't really equipped to deal with that right now. So for now at > least, I think computed fields should always be read-only. > > Ray > > > > On Tue, Apr 9, 2013 at 1:42 PM, Jesse Martinez <mjesse@gmail.com> wrote: > >> Thanks for this, Ray. Quick questions: where do the functions listed in >> the ui-func attribute get defined? And are UI component/Event Handler >> fields always read-only? (I assume they should be, but curious about any >> cases where it wouldn't.) >> >> - Jesse >> >> >> On Tue, Apr 9, 2013 at 3:34 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >>> 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 >>>>>> >>>>>> >>>>> >>>> >>> >> >