I'm modifying the object cataloging record, and I have two problems that I can't figure out. See the attached image for the pictorial view. #1: I'm adding a text field ('ownerNote') to the `objectHistoryAssociationInformation` section. Data that is put into this field is not saved. Based on advice I got from Chad, when a field doesn't save and the label doesn't appear, it means that there is something wrong in the record XML (first URL below). The merged XML (second URL below) looks fine to me, though... sdmom-collectionobject.xml: https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169> merged file output: https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> label defined in core-message.properties-overlay https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130> #2: I've added a `objectViewersContributionInformation` section that mimics somewhat the existing `objectViewerContributionInformation` except that it allows for the field group to repeat. In this case, I /CAN/ save data to the database, but I'm still not getting the labels. sdmom-collectionobject.xml https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186> merged file output: https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> labels defined in core-message.properties-overlay https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> Any thoughts on these? I've managed to work out everything else (including creating a new extension set!), but these have me stumped. Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, For #1, it's not possible to add a field in an extension schema to a repeat in the common schema. You actually have to re-implement the whole repeating group in your local schema, with the additional fields you want. For #2, the way to debug is to look at the "uispec", which is the JSON configuration that the app layer sends to the UI layer, generated from the app layer config. If you open your cataloging record in Chrome, and in the Network tab filter on "uispec", you'll see the contents of that file. In the JSON, you'll see a key that looks like .csc-[your field name]-label, which has a "messagekey" child. That will contain the expected message key in the bundle. Hope that helps! Ray On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com> wrote: > I'm modifying the object cataloging record, and I have two problems that I > can't figure out. See the attached image for the pictorial view. > > > #1: I'm adding a text field ('ownerNote') to the > `objectHistoryAssociationInformation` section. Data that is put into this > field is not saved. Based on advice I got from Chad, when a field doesn't > save and the label doesn't appear, it means that there is something wrong > in the record XML (first URL below). The merged XML (second URL below) > looks fine to me, though... > > sdmom-collectionobject.xml: > > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 > > merged file output: > > https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 > > label defined in core-message.properties-overlay > > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 > > > #2: I've added a `objectViewersContributionInformation` section that > mimics somewhat the existing `objectViewerContributionInformation` except > that it allows for the field group to repeat. In this case, I /CAN/ save > data to the database, but I'm still not getting the labels. > > sdmom-collectionobject.xml > > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 > > merged file output: > > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 > > labels defined in core-message.properties-overlay > > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 > > Any thoughts on these? I've managed to work out everything else > (including creating a new extension set!), but these have me stumped. > > > Peter > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

My apologies for letting the thread drop -- I've been at the NISO forum on discovery services the past couple days. #1: Hmm, okay. Odd -- the merged file output looked okay, so I thought I was good-to-go. Moving the entire contents of the <repeat> element into the sdmom-collectionobject.xml file didn't help -- the results are unchanged. I've copied the merged collection-object XML file into a Gist: https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> Aside: I haven't found where these sorts of quirks are covered in the Configuration Reference Documentation. Am I missing something, or would this be a good thing to add to that documentation? Related question: Is there a way to negate/remove a chunk of the base XML document using directives in the document to be merged? It would actually help with troubleshooting a bit if I could make the unused parts of the schema go away -- even if for just a brief period of time. #2: Thanks for the hint to look at the `uispec` JSON resource. That helped a little bit, I think. I now have a situation where one of four fields in the repeating group has a label. I can't find the difference between the one with the label and the ones without. For instance, the definition for the viewer name all aligns: FIELD DEFINITION in merged XML https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975> FIELD LABEL in core-messages.bundle-overlay https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134> FIELD DEFINITION in HTML template https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626> FIELD DEFINITION in uispec https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707> FIELD LABEL DEFINITION in uispec https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258> ...but this definition for 'viewer role' does not: FIELD DEFINITION in merged XML https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978> FIELD LABEL in core-messages.bundle-overlay https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135> FIELD DEFINITION in HTML template https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637> FIELD DEFINITION in uispec https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694> FIELD LABEL DEFINITION in uispec https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747> Perhaps more puzzled now than I was before... Peter > On Oct 5, 2015, at 4:31 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > For #1, it's not possible to add a field in an extension schema to a repeat in the common schema. You actually have to re-implement the whole repeating group in your local schema, with the additional fields you want. > > For #2, the way to debug is to look at the "uispec", which is the JSON configuration that the app layer sends to the UI layer, generated from the app layer config. If you open your cataloging record in Chrome, and in the Network tab filter on "uispec", you'll see the contents of that file. In the JSON, you'll see a key that looks like .csc-[your field name]-label, which has a "messagekey" child. That will contain the expected message key in the bundle. > > Hope that helps! > > Ray > > > On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > I'm modifying the object cataloging record, and I have two problems that I can't figure out. See the attached image for the pictorial view. > > <PastedGraphic-2.tiff> > > #1: I'm adding a text field ('ownerNote') to the `objectHistoryAssociationInformation` section. Data that is put into this field is not saved. Based on advice I got from Chad, when a field doesn't save and the label doesn't appear, it means that there is something wrong in the record XML (first URL below). The merged XML (second URL below) looks fine to me, though... > > sdmom-collectionobject.xml: > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169> > > merged file output: > https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> > > label defined in core-message.properties-overlay > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130> > > > #2: I've added a `objectViewersContributionInformation` section that mimics somewhat the existing `objectViewerContributionInformation` except that it allows for the field group to repeat. In this case, I /CAN/ save data to the database, but I'm still not getting the labels. > > sdmom-collectionobject.xml > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186> > > merged file output: > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> > > labels defined in core-message.properties-overlay > https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> > > Any thoughts on these? I've managed to work out everything else (including creating a new extension set!), but these have me stumped. > > > Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, > Related question: Is there a way to negate/remove a chunk of the base XML document using directives in the document to be merged? It would actually help with troubleshooting a bit if I could make the unused parts of the schema go away -- even if for just a brief period of time. Regarding this question, one possible place to look might be in the XMLMerge readme file; it's a PDF doc in the Services source code tree on GitHub: https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/XMLMerge-README.pdf And the following is a good introductory article. The delete action is discussed on page 2 of the article, with a slightly longer, more helpful description than in the readme, and including an example, too: http://www.javaworld.com/article/2077736/open-source-tools/xml-merging-made-easy.html?page=2 I'm not sure what combination of in-line actions and/or changes to a merge properties file might be needed to remove extraneous elements from the original, but these docs imply that it should be do-able. Aron On Wed, Oct 7, 2015 at 6:35 PM, Peter Murray <pmurray@chillco.com> wrote: > My apologies for letting the thread drop -- I've been at the NISO forum on > discovery services the past couple days. > > #1: Hmm, okay. Odd -- the merged file output looked okay, so I thought I > was good-to-go. Moving the entire contents of the <repeat> element into > the sdmom-collectionobject.xml file didn't help -- the results are > unchanged. I've copied the merged collection-object XML file into a Gist: > > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 > > Aside: I haven't found where these sorts of quirks are covered in the > Configuration Reference Documentation. Am I missing something, or would > this be a good thing to add to that documentation? > > Related question: Is there a way to negate/remove a chunk of the base XML > document using directives in the document to be merged? It would actually > help with troubleshooting a bit if I could make the unused parts of the > schema go away -- even if for just a brief period of time. > > #2: Thanks for the hint to look at the `uispec` JSON resource. That > helped a little bit, I think. I now have a situation where one of four > fields in the repeating group has a label. I can't find the difference > between the one with the label and the ones without. For instance, the > definition for the viewer name all aligns: > > FIELD DEFINITION in merged XML > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975 > > FIELD LABEL in core-messages.bundle-overlay > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134 > > FIELD DEFINITION in HTML template > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626 > > FIELD DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707 > > FIELD LABEL DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258 > > ...but this definition for 'viewer role' does not: > > FIELD DEFINITION in merged XML > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978 > > FIELD LABEL in core-messages.bundle-overlay > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135 > > FIELD DEFINITION in HTML template > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637 > > FIELD DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694 > > FIELD LABEL DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747 > > > Perhaps more puzzled now than I was before... > > > Peter > > On Oct 5, 2015, at 4:31 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > For #1, it's not possible to add a field in an extension schema to a > repeat in the common schema. You actually have to re-implement the whole > repeating group in your local schema, with the additional fields you want. > > For #2, the way to debug is to look at the "uispec", which is the JSON > configuration that the app layer sends to the UI layer, generated from the > app layer config. If you open your cataloging record in Chrome, and in the > Network tab filter on "uispec", you'll see the contents of that file. In > the JSON, you'll see a key that looks like .csc-[your field name]-label, > which has a "messagekey" child. That will contain the expected message key > in the bundle. > > Hope that helps! > > Ray > > > On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com> wrote: > >> I'm modifying the object cataloging record, and I have two problems that >> I can't figure out. See the attached image for the pictorial view. >> >> <PastedGraphic-2.tiff> >> >> #1: I'm adding a text field ('ownerNote') to the >> `objectHistoryAssociationInformation` section. Data that is put into this >> field is not saved. Based on advice I got from Chad, when a field doesn't >> save and the label doesn't appear, it means that there is something wrong >> in the record XML (first URL below). The merged XML (second URL below) >> looks fine to me, though... >> >> sdmom-collectionobject.xml: >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 >> >> merged file output: >> >> https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 >> >> label defined in core-message.properties-overlay >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 >> >> >> #2: I've added a `objectViewersContributionInformation` section that >> mimics somewhat the existing `objectViewerContributionInformation` except >> that it allows for the field group to repeat. In this case, I /CAN/ save >> data to the database, but I'm still not getting the labels. >> >> sdmom-collectionobject.xml >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 >> >> merged file output: >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 >> >> labels defined in core-message.properties-overlay >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 >> >> Any thoughts on these? I've managed to work out everything else >> (including creating a new extension set!), but these have me stumped. >> >> >> Peter >> > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Thanks, Aron -- I'll take a look. Peter > On Oct 7, 2015, at 10:05 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > > Hi Peter, > > > Related question: Is there a way to negate/remove a chunk of the base XML document using directives in the document to be merged? It would actually help with troubleshooting a bit if I could make the unused parts of the schema go away -- even if for just a brief period of time. > > Regarding this question, one possible place to look might be in the XMLMerge readme file; it's a PDF doc in the Services source code tree on GitHub: > > https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/XMLMerge-README.pdf <https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/XMLMerge-README.pdf> > > And the following is a good introductory article. The delete action is discussed on page 2 of the article, with a slightly longer, more helpful description than in the readme, and including an example, too: > > http://www.javaworld.com/article/2077736/open-source-tools/xml-merging-made-easy.html?page=2 <http://www.javaworld.com/article/2077736/open-source-tools/xml-merging-made-easy.html?page=2> > > I'm not sure what combination of in-line actions and/or changes to a merge properties file might be needed to remove extraneous elements from the original, but these docs imply that it should be do-able. > > Aron > > On Wed, Oct 7, 2015 at 6:35 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > My apologies for letting the thread drop -- I've been at the NISO forum on discovery services the past couple days. > > #1: Hmm, okay. Odd -- the merged file output looked okay, so I thought I was good-to-go. Moving the entire contents of the <repeat> element into the sdmom-collectionobject.xml file didn't help -- the results are unchanged. I've copied the merged collection-object XML file into a Gist: > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> > > Aside: I haven't found where these sorts of quirks are covered in the Configuration Reference Documentation. Am I missing something, or would this be a good thing to add to that documentation? > > Related question: Is there a way to negate/remove a chunk of the base XML document using directives in the document to be merged? It would actually help with troubleshooting a bit if I could make the unused parts of the schema go away -- even if for just a brief period of time. > > #2: Thanks for the hint to look at the `uispec` JSON resource. That helped a little bit, I think. I now have a situation where one of four fields in the repeating group has a label. I can't find the difference between the one with the label and the ones without. For instance, the definition for the viewer name all aligns: > > FIELD DEFINITION in merged XML > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975> > > FIELD LABEL in core-messages.bundle-overlay > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134> > > FIELD DEFINITION in HTML template > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626> > > FIELD DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707> > > FIELD LABEL DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258> > > ...but this definition for 'viewer role' does not: > > FIELD DEFINITION in merged XML > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978> > > FIELD LABEL in core-messages.bundle-overlay > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135> > > FIELD DEFINITION in HTML template > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637> > > FIELD DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694> > > FIELD LABEL DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747> > > Perhaps more puzzled now than I was before... > > > Peter > >> On Oct 5, 2015, at 4:31 PM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: >> >> Hi Peter, >> For #1, it's not possible to add a field in an extension schema to a repeat in the common schema. You actually have to re-implement the whole repeating group in your local schema, with the additional fields you want. >> >> For #2, the way to debug is to look at the "uispec", which is the JSON configuration that the app layer sends to the UI layer, generated from the app layer config. If you open your cataloging record in Chrome, and in the Network tab filter on "uispec", you'll see the contents of that file. In the JSON, you'll see a key that looks like .csc-[your field name]-label, which has a "messagekey" child. That will contain the expected message key in the bundle. >> >> Hope that helps! >> >> Ray >> >> >> On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> I'm modifying the object cataloging record, and I have two problems that I can't figure out. See the attached image for the pictorial view. >> >> <PastedGraphic-2.tiff> >> >> #1: I'm adding a text field ('ownerNote') to the `objectHistoryAssociationInformation` section. Data that is put into this field is not saved. Based on advice I got from Chad, when a field doesn't save and the label doesn't appear, it means that there is something wrong in the record XML (first URL below). The merged XML (second URL below) looks fine to me, though... >> >> sdmom-collectionobject.xml: >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169> >> >> merged file output: >> https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> >> >> label defined in core-message.properties-overlay >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130> >> >> >> #2: I've added a `objectViewersContributionInformation` section that mimics somewhat the existing `objectViewerContributionInformation` except that it allows for the field group to repeat. In this case, I /CAN/ save data to the database, but I'm still not getting the labels. >> >> sdmom-collectionobject.xml >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186> >> >> merged file output: >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> >> >> labels defined in core-message.properties-overlay >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> >> >> Any thoughts on these? I've managed to work out everything else (including creating a new extension set!), but these have me stumped. >> >> >> Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, For #1, you need to implement the whole repeating group in your extension. So the XML should look something like: <repeat id="sdmomOwnerGroupList/sdmomOwner" section="sdmom"> <field id="sdmomOwner" autocomplete="person-person,organization-organization" section="sdmom"/> <field id="sdmomOwnerNote" section="sdmom" /> </repeat> And then in your UI, you'll want to hide/remove the standard owners field, and replace it with your repeating group. The idea is that in the common schema, owners is not a repeating field group, it's just a single repeating field. You're not allowed to change it into a group that can contain multiple fields, so you have to replace it altogether. For #2, I'd like to suggest some things that might help. I've learned to do things a certain way, based on lots of trial and error and working around weird CSpace issues. Here's how I would do the configuration: <section id="objectViewersContributionInformation"> <repeat id="viewersGroupList/viewersGroup" section="sdmom"> <field id="viewer" autocomplete="person-person,organization-organization" section="sdmom"/> <field id="viewerRole" autocomplete="vocab-viewerRole" ui-type="enum" section="sdmom"/> <field id="viewerDate" ui-type="date" datatype="date" ui-search="range" section="sdmom"/> <field id="viewerNote" section="sdmom"/> </repeat> </section> Here's what I changed: - Remove the section attribute from the section tag. It's not necessary. Note the dual-meaning of "section". As an attribute, it really means "schema". As a tag, it... doesn't really do anything. It's just a lexical grouping. By convention, section tags correspond to expanding sections in the UI, but they don't have to. Section tags do actually have one really unintuitive effect, which I won't even go into here because it's crazy. - Change "viewersList/viewersGroup" to "viewersGroupList/viewersGroup". That's convention, and it might make a difference when schemas are generated, because that code relies a lot on convention. - Remove the selector tags. In my opinion they only serve to obfuscate things, by making the class names you use in the HTML not correspond to the ids you use in the XML. Here's an example: App layer config: https://github.com/cspace-deployment/application/blob/bampfa_4.1/tomcat-main/src/main/resources/tenants/bampfa/bampfa-collectionobject.xml#L154-L158 HTML template: https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/html/pages/CatalogingTemplate.html#L78-L100 Message bundle: https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/bundle/core-messages.properties-overlay#L58-L61 Hope that helps! Ray On Wed, Oct 7, 2015 at 6:35 PM, Peter Murray <pmurray@chillco.com> wrote: > My apologies for letting the thread drop -- I've been at the NISO forum on > discovery services the past couple days. > > #1: Hmm, okay. Odd -- the merged file output looked okay, so I thought I > was good-to-go. Moving the entire contents of the <repeat> element into > the sdmom-collectionobject.xml file didn't help -- the results are > unchanged. I've copied the merged collection-object XML file into a Gist: > > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 > > Aside: I haven't found where these sorts of quirks are covered in the > Configuration Reference Documentation. Am I missing something, or would > this be a good thing to add to that documentation? > > Related question: Is there a way to negate/remove a chunk of the base XML > document using directives in the document to be merged? It would actually > help with troubleshooting a bit if I could make the unused parts of the > schema go away -- even if for just a brief period of time. > > #2: Thanks for the hint to look at the `uispec` JSON resource. That > helped a little bit, I think. I now have a situation where one of four > fields in the repeating group has a label. I can't find the difference > between the one with the label and the ones without. For instance, the > definition for the viewer name all aligns: > > FIELD DEFINITION in merged XML > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975 > > FIELD LABEL in core-messages.bundle-overlay > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134 > > FIELD DEFINITION in HTML template > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626 > > FIELD DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707 > > FIELD LABEL DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258 > > ...but this definition for 'viewer role' does not: > > FIELD DEFINITION in merged XML > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978 > > FIELD LABEL in core-messages.bundle-overlay > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135 > > FIELD DEFINITION in HTML template > > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637 > > FIELD DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694 > > FIELD LABEL DEFINITION in uispec > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747 > > > Perhaps more puzzled now than I was before... > > > Peter > > On Oct 5, 2015, at 4:31 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > For #1, it's not possible to add a field in an extension schema to a > repeat in the common schema. You actually have to re-implement the whole > repeating group in your local schema, with the additional fields you want. > > For #2, the way to debug is to look at the "uispec", which is the JSON > configuration that the app layer sends to the UI layer, generated from the > app layer config. If you open your cataloging record in Chrome, and in the > Network tab filter on "uispec", you'll see the contents of that file. In > the JSON, you'll see a key that looks like .csc-[your field name]-label, > which has a "messagekey" child. That will contain the expected message key > in the bundle. > > Hope that helps! > > Ray > > > On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com> wrote: > >> I'm modifying the object cataloging record, and I have two problems that >> I can't figure out. See the attached image for the pictorial view. >> >> <PastedGraphic-2.tiff> >> >> #1: I'm adding a text field ('ownerNote') to the >> `objectHistoryAssociationInformation` section. Data that is put into this >> field is not saved. Based on advice I got from Chad, when a field doesn't >> save and the label doesn't appear, it means that there is something wrong >> in the record XML (first URL below). The merged XML (second URL below) >> looks fine to me, though... >> >> sdmom-collectionobject.xml: >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 >> >> merged file output: >> >> https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 >> >> label defined in core-message.properties-overlay >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 >> >> >> #2: I've added a `objectViewersContributionInformation` section that >> mimics somewhat the existing `objectViewerContributionInformation` except >> that it allows for the field group to repeat. In this case, I /CAN/ save >> data to the database, but I'm still not getting the labels. >> >> sdmom-collectionobject.xml >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 >> >> merged file output: >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 >> >> labels defined in core-message.properties-overlay >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 >> >> Any thoughts on these? I've managed to work out everything else >> (including creating a new extension set!), but these have me stumped. >> >> >> Peter >> > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > >

Thanks, Ray -- those suggestions did the trick. With #1, it makes sense in retrospect that I couldn't redefine the owner field that way. With #2: > Remove the section attribute from the section tag. It's not necessary. Note the dual-meaning of "section". As an attribute, it really means "schema". As a tag, it... doesn't really do anything. It's just a lexical grouping. By convention, section tags correspond to expanding sections in the UI, but they don't have to. Section tags do actually have one really unintuitive effect, which I won't even go into here because it's crazy. Well, that said, how likely am I to run into the unintuitive effect? ;-) > Change "viewersList/viewersGroup" to "viewersGroupList/viewersGroup". That's convention, and it might make a difference when schemas are generated, because that code relies a lot on convention. Yes, the naming convention part it what is killing me. There is a lot of hidden complexity in the naming of things, and the right naming of things. I thought the naming convention for repeated groups was "blahList/blahGroup" (https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field%2C+Group%2C+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup <https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field,+Group,+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup>), but using your suggestion I found that "blahGroupList/blahGroup" did work. If I had known there were so many hidden conventions built into the configuration, I probably would have started a list of them as I found them. I guess I don't know if I'm any closer to the end of finding the conventions than I am to the start... > Remove the selector tags. In my opinion they only serve to obfuscate things, by making the class names you use in the HTML not correspond to the ids you use in the XML. Oh, interesting! I had interpreted the opposite based on just handling the various base configurations and extensions. I certainly find it easier to follow the convention of "csc-collection-object-{fieldName}" in switching between the config and the template, so I'll keep going down that path. So I think this takes me to the end of the config/UI questions. Now I'm up to the data loading questions. And I'm afraid I'm stuck again, but that is another post... Peter > On Oct 9, 2015, at 4:13 AM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > For #1, you need to implement the whole repeating group in your extension. So the XML should look something like: > > <repeat id="sdmomOwnerGroupList/sdmomOwner" section="sdmom"> > <field id="sdmomOwner" autocomplete="person-person,organization-organization" section="sdmom"/> > <field id="sdmomOwnerNote" section="sdmom" /> > </repeat> > > And then in your UI, you'll want to hide/remove the standard owners field, and replace it with your repeating group. The idea is that in the common schema, owners is not a repeating field group, it's just a single repeating field. You're not allowed to change it into a group that can contain multiple fields, so you have to replace it altogether. > > For #2, I'd like to suggest some things that might help. I've learned to do things a certain way, based on lots of trial and error and working around weird CSpace issues. Here's how I would do the configuration: > > <section id="objectViewersContributionInformation"> > <repeat id="viewersGroupList/viewersGroup" section="sdmom"> > <field id="viewer" autocomplete="person-person,organization-organization" section="sdmom"/> > <field id="viewerRole" autocomplete="vocab-viewerRole" ui-type="enum" section="sdmom"/> > <field id="viewerDate" ui-type="date" datatype="date" ui-search="range" section="sdmom"/> > <field id="viewerNote" section="sdmom"/> > </repeat> > </section> > > Here's what I changed: > Remove the section attribute from the section tag. It's not necessary. Note the dual-meaning of "section". As an attribute, it really means "schema". As a tag, it... doesn't really do anything. It's just a lexical grouping. By convention, section tags correspond to expanding sections in the UI, but they don't have to. Section tags do actually have one really unintuitive effect, which I won't even go into here because it's crazy. > Change "viewersList/viewersGroup" to "viewersGroupList/viewersGroup". That's convention, and it might make a difference when schemas are generated, because that code relies a lot on convention. > Remove the selector tags. In my opinion they only serve to obfuscate things, by making the class names you use in the HTML not correspond to the ids you use in the XML. > Here's an example: > > App layer config: > > https://github.com/cspace-deployment/application/blob/bampfa_4.1/tomcat-main/src/main/resources/tenants/bampfa/bampfa-collectionobject.xml#L154-L158 <https://github.com/cspace-deployment/application/blob/bampfa_4.1/tomcat-main/src/main/resources/tenants/bampfa/bampfa-collectionobject.xml#L154-L158> > > HTML template: > > https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/html/pages/CatalogingTemplate.html#L78-L100 <https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/html/pages/CatalogingTemplate.html#L78-L100> > > Message bundle: > > https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/bundle/core-messages.properties-overlay#L58-L61 <https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/bundle/core-messages.properties-overlay#L58-L61> > > Hope that helps! > Ray > > > On Wed, Oct 7, 2015 at 6:35 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > My apologies for letting the thread drop -- I've been at the NISO forum on discovery services the past couple days. > > #1: Hmm, okay. Odd -- the merged file output looked okay, so I thought I was good-to-go. Moving the entire contents of the <repeat> element into the sdmom-collectionobject.xml file didn't help -- the results are unchanged. I've copied the merged collection-object XML file into a Gist: > > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> > > Aside: I haven't found where these sorts of quirks are covered in the Configuration Reference Documentation. Am I missing something, or would this be a good thing to add to that documentation? > > Related question: Is there a way to negate/remove a chunk of the base XML document using directives in the document to be merged? It would actually help with troubleshooting a bit if I could make the unused parts of the schema go away -- even if for just a brief period of time. > > #2: Thanks for the hint to look at the `uispec` JSON resource. That helped a little bit, I think. I now have a situation where one of four fields in the repeating group has a label. I can't find the difference between the one with the label and the ones without. For instance, the definition for the viewer name all aligns: > > FIELD DEFINITION in merged XML > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975> > > FIELD LABEL in core-messages.bundle-overlay > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134> > > FIELD DEFINITION in HTML template > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626> > > FIELD DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707> > > FIELD LABEL DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258> > > ...but this definition for 'viewer role' does not: > > FIELD DEFINITION in merged XML > https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978> > > FIELD LABEL in core-messages.bundle-overlay > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135> > > FIELD DEFINITION in HTML template > https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637> > > FIELD DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694> > > FIELD LABEL DEFINITION in uispec > https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747> > > Perhaps more puzzled now than I was before... > > > Peter > >> On Oct 5, 2015, at 4:31 PM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: >> >> Hi Peter, >> For #1, it's not possible to add a field in an extension schema to a repeat in the common schema. You actually have to re-implement the whole repeating group in your local schema, with the additional fields you want. >> >> For #2, the way to debug is to look at the "uispec", which is the JSON configuration that the app layer sends to the UI layer, generated from the app layer config. If you open your cataloging record in Chrome, and in the Network tab filter on "uispec", you'll see the contents of that file. In the JSON, you'll see a key that looks like .csc-[your field name]-label, which has a "messagekey" child. That will contain the expected message key in the bundle. >> >> Hope that helps! >> >> Ray >> >> >> On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> I'm modifying the object cataloging record, and I have two problems that I can't figure out. See the attached image for the pictorial view. >> >> <PastedGraphic-2.tiff> >> >> #1: I'm adding a text field ('ownerNote') to the `objectHistoryAssociationInformation` section. Data that is put into this field is not saved. Based on advice I got from Chad, when a field doesn't save and the label doesn't appear, it means that there is something wrong in the record XML (first URL below). The merged XML (second URL below) looks fine to me, though... >> >> sdmom-collectionobject.xml: >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169> >> >> merged file output: >> https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> >> >> label defined in core-message.properties-overlay >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130> >> >> >> #2: I've added a `objectViewersContributionInformation` section that mimics somewhat the existing `objectViewerContributionInformation` except that it allows for the field group to repeat. In this case, I /CAN/ save data to the database, but I'm still not getting the labels. >> >> sdmom-collectionobject.xml >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186> >> >> merged file output: >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> >> >> labels defined in core-message.properties-overlay >> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> >> >> Any thoughts on these? I've managed to work out everything else (including creating a new extension set!), but these have me stumped. >> >> >> Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

- Remove the section attribute from the section tag. It's not
necessary. Note the dual-meaning of "section". As an attribute, it really
means "schema". As a tag, it... doesn't really do anything. It's just a
lexical grouping. By convention, section tags correspond to expanding
sections in the UI, but they don't have to. Section tags do actually have
one really unintuitive effect, which I won't even go into here because it's
crazy.

- Change "viewersList/viewersGroup" to
"viewersGroupList/viewersGroup". That's convention, and it might make a
difference when schemas are generated, because that code relies a lot on
convention.

- Remove the selector tags. In my opinion they only serve to obfuscate
things, by making the class names you use in the HTML not correspond to the
ids you use in the XML.

- Remove the section attribute from the section tag. It's not
necessary. Note the dual-meaning of "section". As an attribute, it really
means "schema". As a tag, it... doesn't really do anything. It's just a
lexical grouping. By convention, section tags correspond to expanding
sections in the UI, but they don't have to. Section tags do actually have
one really unintuitive effect, which I won't even go into here because it's
crazy.
- Change "viewersList/viewersGroup" to
"viewersGroupList/viewersGroup". That's convention, and it might make a
difference when schemas are generated, because that code relies a lot on
convention.
- Remove the selector tags. In my opinion they only serve to obfuscate
things, by making the class names you use in the HTML not correspond to the
ids you use in the XML.

> Yes, the naming convention part it what is killing me. There is a lot of hidden complexity in the naming of things, and the right naming of things. I thought the naming convention for repeated groups was "blahList/blahGroup" ( https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field%2C+Group%2C+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup <https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field,+Group,+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup>), but using your suggestion I found that "blahGroupList/blahGroup" did work. If I had known there were so many hidden conventions built into the configuration, I probably would have started a list of them as I found them. I guess I don't know if I'm any closer to the end of finding the conventions than I am to the start... As one of Ursula Le Guin's characters once said, in a now 50-year-old short story (https://en.wikipedia.org/wiki/The_Rule_of_Names): "The name is the thing ... and the truename is the true thing. To speak the name is to control the thing ..." Yes. YES. Naming has been one of the giant bugaboos in CSpace. If we were to start this project over again, heeding key lessons we learned from its creation, I'd suggest that one of those lessons would be: "Spend two or three times as much time as you first believe you can possibly ever devote, to coming up with really good names for things, and on developing naming conventions. This time will not be wasted; in the long run, it's likely to more than pay for itself. Ruthlessly weed out any inconsistencies in these names and in your naming conventions. And document the heck out of those conventions." An example is the use of blahGroupList/blahGroup (and also blahList) as a naming convention for lists of repeatable (aka multivalued) groups of fields, repeatable groups of fields, and repeatable (multivalued) fields. IIRC, Rick Jaffe and I were among those agonizing over and coming up with those conventions. Whether those names are optimally intuitive, they were at least intended to be consistent. However, they were introduced too late to be made pervasive. (Some additional thoughts about conventions can be seen here: https://wiki.collectionspace.org/display/~aronr/Proposed+naming+conventions+for+fields+in+services+payloads; this follow-up change was never implemented, AFAIK.) Aron P.S. Andy Oppel (bio: https://www.linkedin.com/pub/andy-oppel/2/830/900) has made his living as a sought-after database modeler; he also has written a number of books and taught courses in that field. If memory serves, in one of his UC Extension courses, he once described his job as substantially about "giving good names to things." On Mon, Oct 12, 2015 at 12:19 PM, Peter Murray <pmurray@chillco.com> wrote: > Thanks, Ray -- those suggestions did the trick. With #1, it makes sense > in retrospect that I couldn't redefine the owner field that way. With #2: > > > - Remove the section attribute from the section tag. It's not > necessary. Note the dual-meaning of "section". As an attribute, it really > means "schema". As a tag, it... doesn't really do anything. It's just a > lexical grouping. By convention, section tags correspond to expanding > sections in the UI, but they don't have to. Section tags do actually have > one really unintuitive effect, which I won't even go into here because it's > crazy. > > > Well, that said, how likely am I to run into the unintuitive effect? ;-) > > > - Change "viewersList/viewersGroup" to > "viewersGroupList/viewersGroup". That's convention, and it might make a > difference when schemas are generated, because that code relies a lot on > convention. > > > Yes, the naming convention part it what is killing me. There is a lot of > hidden complexity in the naming of things, and the right naming of things. > I thought the naming convention for repeated groups was > "blahList/blahGroup" ( > https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field%2C+Group%2C+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup > <https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field,+Group,+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup>), > but using your suggestion I found that "blahGroupList/blahGroup" did work. > If I had known there were so many hidden conventions built into the > configuration, I probably would have started a list of them as I found > them. I guess I don't know if I'm any closer to the end of finding the > conventions than I am to the start... > > > - Remove the selector tags. In my opinion they only serve to obfuscate > things, by making the class names you use in the HTML not correspond to the > ids you use in the XML. > > > Oh, interesting! I had interpreted the opposite based on just handling > the various base configurations and extensions. I certainly find it easier > to follow the convention of "csc-collection-object-{fieldName}" in > switching between the config and the template, so I'll keep going down that > path. > > So I think this takes me to the end of the config/UI questions. Now I'm > up to the data loading questions. And I'm afraid I'm stuck again, but that > is another post... > > > Peter > > > On Oct 9, 2015, at 4:13 AM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > For #1, you need to implement the whole repeating group in your extension. > So the XML should look something like: > > <repeat id="sdmomOwnerGroupList/sdmomOwner" section="sdmom"> > <field id="sdmomOwner" > autocomplete="person-person,organization-organization" section="sdmom"/> > <field id="sdmomOwnerNote" section="sdmom" /> > </repeat> > > And then in your UI, you'll want to hide/remove the standard owners field, > and replace it with your repeating group. The idea is that in the common > schema, owners is not a repeating field group, it's just a single repeating > field. You're not allowed to change it into a group that can contain > multiple fields, so you have to replace it altogether. > > For #2, I'd like to suggest some things that might help. I've learned to > do things a certain way, based on lots of trial and error and working > around weird CSpace issues. Here's how I would do the configuration: > > <section id="objectViewersContributionInformation"> > <repeat id="viewersGroupList/viewersGroup" section="sdmom"> > <field id="viewer" > autocomplete="person-person,organization-organization" section="sdmom"/> > <field id="viewerRole" autocomplete="vocab-viewerRole" ui-type="enum" > section="sdmom"/> > <field id="viewerDate" ui-type="date" datatype="date" > ui-search="range" section="sdmom"/> > <field id="viewerNote" section="sdmom"/> > </repeat> > </section> > > Here's what I changed: > > - Remove the section attribute from the section tag. It's not > necessary. Note the dual-meaning of "section". As an attribute, it really > means "schema". As a tag, it... doesn't really do anything. It's just a > lexical grouping. By convention, section tags correspond to expanding > sections in the UI, but they don't have to. Section tags do actually have > one really unintuitive effect, which I won't even go into here because it's > crazy. > - Change "viewersList/viewersGroup" to > "viewersGroupList/viewersGroup". That's convention, and it might make a > difference when schemas are generated, because that code relies a lot on > convention. > - Remove the selector tags. In my opinion they only serve to obfuscate > things, by making the class names you use in the HTML not correspond to the > ids you use in the XML. > > Here's an example: > > App layer config: > > > https://github.com/cspace-deployment/application/blob/bampfa_4.1/tomcat-main/src/main/resources/tenants/bampfa/bampfa-collectionobject.xml#L154-L158 > > HTML template: > > > https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/html/pages/CatalogingTemplate.html#L78-L100 > > Message bundle: > > > https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/bundle/core-messages.properties-overlay#L58-L61 > > Hope that helps! > Ray > > > On Wed, Oct 7, 2015 at 6:35 PM, Peter Murray <pmurray@chillco.com> wrote: > >> My apologies for letting the thread drop -- I've been at the NISO forum >> on discovery services the past couple days. >> >> #1: Hmm, okay. Odd -- the merged file output looked okay, so I thought I >> was good-to-go. Moving the entire contents of the <repeat> element into >> the sdmom-collectionobject.xml file didn't help -- the results are >> unchanged. I've copied the merged collection-object XML file into a Gist: >> >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 >> >> Aside: I haven't found where these sorts of quirks are covered in the >> Configuration Reference Documentation. Am I missing something, or would >> this be a good thing to add to that documentation? >> >> Related question: Is there a way to negate/remove a chunk of the base XML >> document using directives in the document to be merged? It would actually >> help with troubleshooting a bit if I could make the unused parts of the >> schema go away -- even if for just a brief period of time. >> >> #2: Thanks for the hint to look at the `uispec` JSON resource. That >> helped a little bit, I think. I now have a situation where one of four >> fields in the repeating group has a label. I can't find the difference >> between the one with the label and the ones without. For instance, the >> definition for the viewer name all aligns: >> >> FIELD DEFINITION in merged XML >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975 >> >> FIELD LABEL in core-messages.bundle-overlay >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134 >> >> FIELD DEFINITION in HTML template >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626 >> >> FIELD DEFINITION in uispec >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707 >> >> FIELD LABEL DEFINITION in uispec >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258 >> >> ...but this definition for 'viewer role' does not: >> >> FIELD DEFINITION in merged XML >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978 >> >> FIELD LABEL in core-messages.bundle-overlay >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135 >> >> FIELD DEFINITION in HTML template >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637 >> >> FIELD DEFINITION in uispec >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694 >> >> FIELD LABEL DEFINITION in uispec >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747 >> >> >> Perhaps more puzzled now than I was before... >> >> >> Peter >> >> On Oct 5, 2015, at 4:31 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >> Hi Peter, >> For #1, it's not possible to add a field in an extension schema to a >> repeat in the common schema. You actually have to re-implement the whole >> repeating group in your local schema, with the additional fields you want. >> >> For #2, the way to debug is to look at the "uispec", which is the JSON >> configuration that the app layer sends to the UI layer, generated from the >> app layer config. If you open your cataloging record in Chrome, and in the >> Network tab filter on "uispec", you'll see the contents of that file. In >> the JSON, you'll see a key that looks like .csc-[your field name]-label, >> which has a "messagekey" child. That will contain the expected message key >> in the bundle. >> >> Hope that helps! >> >> Ray >> >> >> On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com> wrote: >> >>> I'm modifying the object cataloging record, and I have two problems that >>> I can't figure out. See the attached image for the pictorial view. >>> >>> <PastedGraphic-2.tiff> >>> >>> #1: I'm adding a text field ('ownerNote') to the >>> `objectHistoryAssociationInformation` section. Data that is put into this >>> field is not saved. Based on advice I got from Chad, when a field doesn't >>> save and the label doesn't appear, it means that there is something wrong >>> in the record XML (first URL below). The merged XML (second URL below) >>> looks fine to me, though... >>> >>> sdmom-collectionobject.xml: >>> >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 >>> >>> merged file output: >>> >>> https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 >>> >>> label defined in core-message.properties-overlay >>> >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 >>> >>> >>> #2: I've added a `objectViewersContributionInformation` section that >>> mimics somewhat the existing `objectViewerContributionInformation` except >>> that it allows for the field group to repeat. In this case, I /CAN/ save >>> data to the database, but I'm still not getting the labels. >>> >>> sdmom-collectionobject.xml >>> >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 >>> >>> merged file output: >>> >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 >>> >>> labels defined in core-message.properties-overlay >>> >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 >>> >>> Any thoughts on these? I've managed to work out everything else >>> (including creating a new extension set!), but these have me stumped. >>> >>> >>> Peter >>> >> > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Great references -- I get where you are coming from now, and have a better sense of why things are the way they are. Although I appreciate the brevity of the proposed _L, _G, and _LG extensions, the "List" and "Group" words are more meaningful. The phrase that comes to mind is "Style Guide" when designing the record extensions. There is more than one way to say something, but with a certain amount of precision the whole can be made easier to understand. That might be a good way to surface some of the hidden complexity. Peter > On Oct 13, 2015, at 7:11 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > > > Yes, the naming convention part it what is killing me. There is a lot of hidden complexity in the naming of things, and the right naming of things. I thought the naming convention for repeated groups was "blahList/blahGroup" (https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field%2C+Group%2C+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup <https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field,+Group,+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup>), but using your suggestion I found that "blahGroupList/blahGroup" did work. If I had known there were so many hidden conventions built into the configuration, I probably would have started a list of them as I found them. I guess I don't know if I'm any closer to the end of finding the conventions than I am to the start... > > As one of Ursula Le Guin's characters once said, in a now 50-year-old short story (https://en.wikipedia.org/wiki/The_Rule_of_Names <https://en.wikipedia.org/wiki/The_Rule_of_Names>): > > "The name is the thing ... and the truename is the true thing. To speak the name is to control the thing ..." > > Yes. YES. Naming has been one of the giant bugaboos in CSpace. If we were to start this project over again, heeding key lessons we learned from its creation, I'd suggest that one of those lessons would be: > > "Spend two or three times as much time as you first believe you can possibly ever devote, to coming up with really good names for things, and on developing naming conventions. This time will not be wasted; in the long run, it's likely to more than pay for itself. Ruthlessly weed out any inconsistencies in these names and in your naming conventions. And document the heck out of those conventions." > > An example is the use of blahGroupList/blahGroup (and also blahList) as a naming convention for lists of repeatable (aka multivalued) groups of fields, repeatable groups of fields, and repeatable (multivalued) fields. IIRC, Rick Jaffe and I were among those agonizing over and coming up with those conventions. Whether those names are optimally intuitive, they were at least intended to be consistent. However, they were introduced too late to be made pervasive. (Some additional thoughts about conventions can be seen here: https://wiki.collectionspace.org/display/~aronr/Proposed+naming+conventions+for+fields+in+services+payloads <https://wiki.collectionspace.org/display/~aronr/Proposed+naming+conventions+for+fields+in+services+payloads>; this follow-up change was never implemented, AFAIK.) > > Aron > > P.S. Andy Oppel (bio: https://www.linkedin.com/pub/andy-oppel/2/830/900 <https://www.linkedin.com/pub/andy-oppel/2/830/900>) has made his living as a sought-after database modeler; he also has written a number of books and taught courses in that field. If memory serves, in one of his UC Extension courses, he once described his job as substantially about "giving good names to things." > > > On Mon, Oct 12, 2015 at 12:19 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > Thanks, Ray -- those suggestions did the trick. With #1, it makes sense in retrospect that I couldn't redefine the owner field that way. With #2: > >> Remove the section attribute from the section tag. It's not necessary. Note the dual-meaning of "section". As an attribute, it really means "schema". As a tag, it... doesn't really do anything. It's just a lexical grouping. By convention, section tags correspond to expanding sections in the UI, but they don't have to. Section tags do actually have one really unintuitive effect, which I won't even go into here because it's crazy. > > Well, that said, how likely am I to run into the unintuitive effect? ;-) > >> Change "viewersList/viewersGroup" to "viewersGroupList/viewersGroup". That's convention, and it might make a difference when schemas are generated, because that code relies a lot on convention. > > Yes, the naming convention part it what is killing me. There is a lot of hidden complexity in the naming of things, and the right naming of things. I thought the naming convention for repeated groups was "blahList/blahGroup" (https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field%2C+Group%2C+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup <https://wiki.collectionspace.org/display/DOC/cspace-config+Add+Field,+Group,+Repeat#cspace-configAddField,Group,Repeat-AddaRepeatGroup>), but using your suggestion I found that "blahGroupList/blahGroup" did work. If I had known there were so many hidden conventions built into the configuration, I probably would have started a list of them as I found them. I guess I don't know if I'm any closer to the end of finding the conventions than I am to the start... > >> Remove the selector tags. In my opinion they only serve to obfuscate things, by making the class names you use in the HTML not correspond to the ids you use in the XML. > > Oh, interesting! I had interpreted the opposite based on just handling the various base configurations and extensions. I certainly find it easier to follow the convention of "csc-collection-object-{fieldName}" in switching between the config and the template, so I'll keep going down that path. > > So I think this takes me to the end of the config/UI questions. Now I'm up to the data loading questions. And I'm afraid I'm stuck again, but that is another post... > > > Peter > > >> On Oct 9, 2015, at 4:13 AM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: >> >> Hi Peter, >> For #1, you need to implement the whole repeating group in your extension. So the XML should look something like: >> >> <repeat id="sdmomOwnerGroupList/sdmomOwner" section="sdmom"> >> <field id="sdmomOwner" autocomplete="person-person,organization-organization" section="sdmom"/> >> <field id="sdmomOwnerNote" section="sdmom" /> >> </repeat> >> >> And then in your UI, you'll want to hide/remove the standard owners field, and replace it with your repeating group. The idea is that in the common schema, owners is not a repeating field group, it's just a single repeating field. You're not allowed to change it into a group that can contain multiple fields, so you have to replace it altogether. >> >> For #2, I'd like to suggest some things that might help. I've learned to do things a certain way, based on lots of trial and error and working around weird CSpace issues. Here's how I would do the configuration: >> >> <section id="objectViewersContributionInformation"> >> <repeat id="viewersGroupList/viewersGroup" section="sdmom"> >> <field id="viewer" autocomplete="person-person,organization-organization" section="sdmom"/> >> <field id="viewerRole" autocomplete="vocab-viewerRole" ui-type="enum" section="sdmom"/> >> <field id="viewerDate" ui-type="date" datatype="date" ui-search="range" section="sdmom"/> >> <field id="viewerNote" section="sdmom"/> >> </repeat> >> </section> >> >> Here's what I changed: >> Remove the section attribute from the section tag. It's not necessary. Note the dual-meaning of "section". As an attribute, it really means "schema". As a tag, it... doesn't really do anything. It's just a lexical grouping. By convention, section tags correspond to expanding sections in the UI, but they don't have to. Section tags do actually have one really unintuitive effect, which I won't even go into here because it's crazy. >> Change "viewersList/viewersGroup" to "viewersGroupList/viewersGroup". That's convention, and it might make a difference when schemas are generated, because that code relies a lot on convention. >> Remove the selector tags. In my opinion they only serve to obfuscate things, by making the class names you use in the HTML not correspond to the ids you use in the XML. >> Here's an example: >> >> App layer config: >> >> https://github.com/cspace-deployment/application/blob/bampfa_4.1/tomcat-main/src/main/resources/tenants/bampfa/bampfa-collectionobject.xml#L154-L158 <https://github.com/cspace-deployment/application/blob/bampfa_4.1/tomcat-main/src/main/resources/tenants/bampfa/bampfa-collectionobject.xml#L154-L158> >> >> HTML template: >> >> https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/html/pages/CatalogingTemplate.html#L78-L100 <https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/html/pages/CatalogingTemplate.html#L78-L100> >> >> Message bundle: >> >> https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/bundle/core-messages.properties-overlay#L58-L61 <https://github.com/cspace-deployment/ui/blob/bampfa_4.1/src/main/webapp/tenants/bampfa/bundle/core-messages.properties-overlay#L58-L61> >> >> Hope that helps! >> Ray >> >> >> On Wed, Oct 7, 2015 at 6:35 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> My apologies for letting the thread drop -- I've been at the NISO forum on discovery services the past couple days. >> >> #1: Hmm, okay. Odd -- the merged file output looked okay, so I thought I was good-to-go. Moving the entire contents of the <repeat> element into the sdmom-collectionobject.xml file didn't help -- the results are unchanged. I've copied the merged collection-object XML file into a Gist: >> >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> >> >> Aside: I haven't found where these sorts of quirks are covered in the Configuration Reference Documentation. Am I missing something, or would this be a good thing to add to that documentation? >> >> Related question: Is there a way to negate/remove a chunk of the base XML document using directives in the document to be merged? It would actually help with troubleshooting a bit if I could make the unused parts of the schema go away -- even if for just a brief period of time. >> >> #2: Thanks for the hint to look at the `uispec` JSON resource. That helped a little bit, I think. I now have a situation where one of four fields in the repeating group has a label. I can't find the difference between the one with the label and the ones without. For instance, the definition for the viewer name all aligns: >> >> FIELD DEFINITION in merged XML >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L973-L975> >> >> FIELD LABEL in core-messages.bundle-overlay >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L134> >> >> FIELD DEFINITION in HTML template >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1619-L1626> >> >> FIELD DEFINITION in uispec >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1695-L1707> >> >> FIELD LABEL DEFINITION in uispec >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1256-L1258> >> >> ...but this definition for 'viewer role' does not: >> >> FIELD DEFINITION in merged XML >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L976-L978> >> >> FIELD LABEL in core-messages.bundle-overlay >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/bundle/core-messages.properties-overlay#L135> >> >> FIELD DEFINITION in HTML template >> https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637 <https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-63/ui/html/pages/CatalogingTemplate.html#L1628-L1637> >> >> FIELD DEFINITION in uispec >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L1682-L1694> >> >> FIELD LABEL DEFINITION in uispec >> https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747 <https://gist.github.com/dltj/4193a651ebc2dff12062#file-uispec-json-L2745-L2747> >> >> Perhaps more puzzled now than I was before... >> >> >> Peter >> >>> On Oct 5, 2015, at 4:31 PM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: >>> >>> Hi Peter, >>> For #1, it's not possible to add a field in an extension schema to a repeat in the common schema. You actually have to re-implement the whole repeating group in your local schema, with the additional fields you want. >>> >>> For #2, the way to debug is to look at the "uispec", which is the JSON configuration that the app layer sends to the UI layer, generated from the app layer config. If you open your cataloging record in Chrome, and in the Network tab filter on "uispec", you'll see the contents of that file. In the JSON, you'll see a key that looks like .csc-[your field name]-label, which has a "messagekey" child. That will contain the expected message key in the bundle. >>> >>> Hope that helps! >>> >>> Ray >>> >>> >>> On Sat, Oct 3, 2015 at 6:22 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>> I'm modifying the object cataloging record, and I have two problems that I can't figure out. See the attached image for the pictorial view. >>> >>> <PastedGraphic-2.tiff> >>> >>> #1: I'm adding a text field ('ownerNote') to the `objectHistoryAssociationInformation` section. Data that is put into this field is not saved. Based on advice I got from Chad, when a field doesn't save and the label doesn't appear, it means that there is something wrong in the record XML (first URL below). The merged XML (second URL below) looks fine to me, though... >>> >>> sdmom-collectionobject.xml: >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L163-L169> >>> >>> merged file output: >>> https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809 <https://gist.github.com/dltj/d26b81f33c08906c21ab#file-merged-base-collectionobject-xml_sdmom-collectionobject-xml-xml-L804-L809> >>> >>> label defined in core-message.properties-overlay >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L130> >>> >>> >>> #2: I've added a `objectViewersContributionInformation` section that mimics somewhat the existing `objectViewerContributionInformation` except that it allows for the field group to repeat. In this case, I /CAN/ save data to the database, but I'm still not getting the labels. >>> >>> sdmom-collectionobject.xml >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/application/sdmom-collectionobject.xml#L171-L186> >>> >>> merged file output: >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> >>> >>> labels defined in core-message.properties-overlay >>> https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136 <https://github.com/cherryhill/sdmom-tenant-config/blob/c2b65885124b4c129a9c5fc4c4b6ccebc042e5b4/ui/bundle/core-messages.properties-overlay#L132-L136> >>> >>> Any thoughts on these? I've managed to work out everything else (including creating a new extension set!), but these have me stumped. >>> >>> >>> Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company