talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsAdding a static list field to application and ui
Having figured out text fields (thanks again!), I'm now trying to add a static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17
UI DEFINITION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51
When I try to save the value in the field, it the UI just cycles back to I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412] Invalid input document. No such property was found [objectStatus] in schema intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note also that I can save a value in the ownersRequirements text field in the same extension. Based on those two factors, I'm pretty sure the extension field definitions are getting merged into the config. In fact, when I look at the results of the XML merge in Tomcat's temp directory, the field seems to be defined:
Looking at the saved record at the API level, though, the field is not there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub now is close to the one that I found in the "HTML field level templates" documentation:
In each cycle of testing, I'm shutting down Tomcat, running the mvn command in application and ui, the ant command in services/services/JaxRsServiceProvider, starting Tomcat, and running the init command on the UI. (I've set it up in an Ansible playbook -- https://gist.github.com/dltj/81dca4e22f4f747cc639 -- so I know all of the steps are run in the right sequence.) I work on the pages using Chrome, and in the Developer Tools I've checked the setting Disable cache (while DevTools is open) -- so I don't think browser caching is the problem. I'm creating a new record with each test (I discovered early on, I think, that I can't edit records that used an old version of the schema and expect them to be updated to the new version on edit).
Peter
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
At first glance, what happens if you add the 'section="sdmom"' attribute
to the 'field' element for this new field, much as you did for
ownersRequirements?
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray pmurray@chillco.com wrote:
Having figured out text fields (thanks again!), I'm now trying to add a
static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
UI DEFINITION
When I try to save the value in the field, it the UI just cycles back to
I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412]
Invalid input document. No such property was found [objectStatus] in schema
intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note
also that I can save a value in the ownersRequirements text field in the
same extension. Based on those two factors, I'm pretty sure the extension
field definitions are getting merged into the config. In fact, when I look
at the results of the XML merge in Tomcat's temp directory, the field
seems to be defined:
Looking at the saved record at the API level, though, the field is not
there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub
now is close to the one that I found in the "HTML field level templates"
documentation:
In each cycle of testing, I'm shutting down Tomcat, running the mvn
command in application and ui, the ant command in
services/services/JaxRsServiceProvider, starting Tomcat, and running the
init command on the UI. (I've set it up in an Ansible playbook --
https://gist.github.com/dltj/81dca4e22f4f747cc639 -- so I know all of the
steps are run in the right sequence.) I work on the pages using Chrome,
and in the Developer Tools I've checked the setting Disable cache (while DevTools is open) -- so I don't think browser caching is the problem. I'm
creating a new record with each test (I discovered early on, I think, that
I can't edit records that used an old version of the schema and expect them
to be updated to the new version on edit).
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
Peter,
A "meta-observation" about the static list you are attempting to create.
We have found here at UCB that static lists are generally a bad idea: at
some point, users want to change or add values, and this then requires
"customization" -- a software engineer skilled in the art needs to make the
changes, commit them, redeploy CSpace, and then do any database updates
that might be required.
Far better, in general, to make all lists "dynamic" -- then users can
manage them on there own without engineering intervention.
There has been a lot of discussion about this, some of it here on this Talk
list, some of it in JIRAs. I'd be happy to track down some details for you.
John
On Tue, Sep 22, 2015 at 1:26 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
At first glance, what happens if you add the 'section="sdmom"'
attribute to the 'field' element for this new field, much as you did for
ownersRequirements?
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray pmurray@chillco.com wrote:
Having figured out text fields (thanks again!), I'm now trying to add a
static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
UI DEFINITION
When I try to save the value in the field, it the UI just cycles back to
I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412]
Invalid input document. No such property was found [objectStatus] in schema
intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note
also that I can save a value in the ownersRequirements text field in the
same extension. Based on those two factors, I'm pretty sure the extension
field definitions are getting merged into the config. In fact, when I look
at the results of the XML merge in Tomcat's temp directory, the field
seems to be defined:
Looking at the saved record at the API level, though, the field is not
there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub
now is close to the one that I found in the "HTML field level templates"
documentation:
In each cycle of testing, I'm shutting down Tomcat, running the mvn
command in application and ui, the ant command in
services/services/JaxRsServiceProvider, starting Tomcat, and running the
init command on the UI. (I've set it up in an Ansible playbook --
https://gist.github.com/dltj/81dca4e22f4f747cc639 -- so I know all of
the steps are run in the right sequence.) I work on the pages using
Chrome, and in the Developer Tools I've checked the setting Disable cache (while DevTools is open) -- so I don't think browser caching is the
problem. I'm creating a new record with each test (I discovered early on,
I think, that I can't edit records that used an old version of the schema
and expect them to be updated to the new version on edit).
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
Geez! It was that easy? That seemed to do the trick. I wonder why it (presumably!) works in other's code without that attribute:
https://github.com/jessemartinez/application/blob/miami/tomcat-main/src/main/resources/tenants/miami/miami-procedure-acquisition.xml#L4-L16 https://github.com/jessemartinez/application/blob/miami/tomcat-main/src/main/resources/tenants/miami/miami-procedure-acquisition.xml#L4-L16
https://github.com/CollectionSpace-Deployments/application/blob/mmi-v4.2/tomcat-main/src/main/resources/tenants/mmi/mmi-procedure-acquisition.xml#L11-L19 https://github.com/CollectionSpace-Deployments/application/blob/mmi-v4.2/tomcat-main/src/main/resources/tenants/mmi/mmi-procedure-acquisition.xml#L11-L19
I am trying to learn the in's and out's of how CSpace configuration is done, so if there is a good answer please let me know. (I figure it'll help me predict what other configuration options are possible or dead ends.)
Peter
On Sep 22, 2015, at 4:26 PM, Aron Roberts aron@socrates.berkeley.edu wrote:
At first glance, what happens if you add the 'section="sdmom"' attribute to the 'field' element for this new field, much as you did for ownersRequirements?
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
Having figured out text fields (thanks again!), I'm now trying to add a static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17
UI DEFINITION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51
When I try to save the value in the field, it the UI just cycles back to I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412] Invalid input document. No such property was found [objectStatus] in schema intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note also that I can save a value in the ownersRequirements text field in the same extension. Based on those two factors, I'm pretty sure the extension field definitions are getting merged into the config. In fact, when I look at the results of the XML merge in Tomcat's temp directory, the field seems to be defined:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101 https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101
Looking at the saved record at the API level, though, the field is not there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub now is close to the one that I found in the "HTML field level templates" documentation:
https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
Thanks for the meta-observation, John. That would be my inclination, too, but I remember hearing (somewhere) that there was a performance penalty for dynamic lists. I imagine there is some database lookup time involved, but I'm not far enough along to be able to quantify whether there is a meaningful difference between static and dynamic lists. Any thoughts on that would be most welcome.
Peter
On Sep 22, 2015, at 4:31 PM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
A "meta-observation" about the static list you are attempting to create.
We have found here at UCB that static lists are generally a bad idea: at some point, users want to change or add values, and this then requires "customization" -- a software engineer skilled in the art needs to make the changes, commit them, redeploy CSpace, and then do any database updates that might be required.
Far better, in general, to make all lists "dynamic" -- then users can manage them on there own without engineering intervention.
There has been a lot of discussion about this, some of it here on this Talk list, some of it in JIRAs. I'd be happy to track down some details for you.
John
On Tue, Sep 22, 2015 at 1:26 PM, Aron Roberts <aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
At first glance, what happens if you add the 'section="sdmom"' attribute to the 'field' element for this new field, much as you did for ownersRequirements?
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
Having figured out text fields (thanks again!), I'm now trying to add a static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17
UI DEFINITION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51
When I try to save the value in the field, it the UI just cycles back to I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412] Invalid input document. No such property was found [objectStatus] in schema intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note also that I can save a value in the ownersRequirements text field in the same extension. Based on those two factors, I'm pretty sure the extension field definitions are getting merged into the config. In fact, when I look at the results of the XML merge in Tomcat's temp directory, the field seems to be defined:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101 https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101
Looking at the saved record at the API level, though, the field is not there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub now is close to the one that I found in the "HTML field level templates" documentation:
https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
Thanks, John, for bringing up this important guidance! (As John notes, by
making the option list dynamic, users can edit its values themselves,
rather than requiring developer intervention to make even the slightest
changes.)
Peter, it's been my experience that dynamic option lists load quickly, in
practice. (This conceivably may in part be due to caching ...
https://wiki.collectionspace.org/display/DOC/Configuring+Caching+in+CollectionSpace
)
Geez! It was that easy? That seemed to do the trick. I wonder why it
(presumably!) works in other's code without that attribute ...
In the two examples you noted, it's possible both of these represented
instances of an existing field in the 'common' schema being overridden
(e.g. redefined) in a tenant-specific configuration file, rather than a new
field being added in an extension schema. (There are instances of fields in
extension schemas being added, elsewhere in those same configuration files,
and those do have the 'section=' attribute.)
On Tue, Sep 22, 2015 at 1:38 PM, Peter Murray pmurray@chillco.com wrote:
Thanks for the meta-observation, John. That would be my inclination, too,
but I remember hearing (somewhere) that there was a performance penalty for
dynamic lists. I imagine there is some database lookup time involved, but
I'm not far enough along to be able to quantify whether there is a
meaningful difference between static and dynamic lists. Any thoughts on
that would be most welcome.
Peter
On Sep 22, 2015, at 4:31 PM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
A "meta-observation" about the static list you are attempting to create.
We have found here at UCB that static lists are generally a bad idea: at
some point, users want to change or add values, and this then requires
"customization" -- a software engineer skilled in the art needs to make the
changes, commit them, redeploy CSpace, and then do any database updates
that might be required.
Far better, in general, to make all lists "dynamic" -- then users can
manage them on there own without engineering intervention.
There has been a lot of discussion about this, some of it here on this
Talk list, some of it in JIRAs. I'd be happy to track down some details for
you.
John
On Tue, Sep 22, 2015 at 1:26 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
At first glance, what happens if you add the 'section="sdmom"'
attribute to the 'field' element for this new field, much as you did for
ownersRequirements?
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray pmurray@chillco.com
wrote:
Having figured out text fields (thanks again!), I'm now trying to add a
static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
UI DEFINITION
When I try to save the value in the field, it the UI just cycles back to
I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412]
Invalid input document. No such property was found [objectStatus] in schema
intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note
also that I can save a value in the ownersRequirements text field in the
same extension. Based on those two factors, I'm pretty sure the extension
field definitions are getting merged into the config. In fact, when I look
at the results of the XML merge in Tomcat's temp directory, the field
seems to be defined:
Looking at the saved record at the API level, though, the field is not
there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub
now is close to the one that I found in the "HTML field level templates"
documentation:
--
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
Ah! Thank you for the dynamic term advice and for the overriding existing fields observation. Little-by-little, I think I'm catching on to "CollectionSpace-think".
Peter
On Sep 22, 2015, at 4:52 PM, Aron Roberts aron@socrates.berkeley.edu wrote:
Thanks, John, for bringing up this important guidance! (As John notes, by making the option list dynamic, users can edit its values themselves, rather than requiring developer intervention to make even the slightest changes.)
Peter, it's been my experience that dynamic option lists load quickly, in practice. (This conceivably may in part be due to caching ... https://wiki.collectionspace.org/display/DOC/Configuring+Caching+in+CollectionSpace https://wiki.collectionspace.org/display/DOC/Configuring+Caching+in+CollectionSpace)
Geez! It was that easy? That seemed to do the trick. I wonder why it (presumably!) works in other's code without that attribute ...
In the two examples you noted, it's possible both of these represented instances of an existing field in the 'common' schema being overridden (e.g. redefined) in a tenant-specific configuration file, rather than a new field being added in an extension schema. (There are instances of fields in extension schemas being added, elsewhere in those same configuration files, and those do have the 'section=' attribute.)
On Tue, Sep 22, 2015 at 1:38 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
Thanks for the meta-observation, John. That would be my inclination, too, but I remember hearing (somewhere) that there was a performance penalty for dynamic lists. I imagine there is some database lookup time involved, but I'm not far enough along to be able to quantify whether there is a meaningful difference between static and dynamic lists. Any thoughts on that would be most welcome.
Peter
On Sep 22, 2015, at 4:31 PM, John B. LOWE <jblowe@berkeley.edu mailto:jblowe@berkeley.edu> wrote:
Peter,
A "meta-observation" about the static list you are attempting to create.
We have found here at UCB that static lists are generally a bad idea: at some point, users want to change or add values, and this then requires "customization" -- a software engineer skilled in the art needs to make the changes, commit them, redeploy CSpace, and then do any database updates that might be required.
Far better, in general, to make all lists "dynamic" -- then users can manage them on there own without engineering intervention.
There has been a lot of discussion about this, some of it here on this Talk list, some of it in JIRAs. I'd be happy to track down some details for you.
John
On Tue, Sep 22, 2015 at 1:26 PM, Aron Roberts <aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
At first glance, what happens if you add the 'section="sdmom"' attribute to the 'field' element for this new field, much as you did for ownersRequirements?
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
Having figured out text fields (thanks again!), I'm now trying to add a static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17
UI DEFINITION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51
When I try to save the value in the field, it the UI just cycles back to I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412] Invalid input document. No such property was found [objectStatus] in schema intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note also that I can save a value in the ownersRequirements text field in the same extension. Based on those two factors, I'm pretty sure the extension field definitions are getting merged into the config. In fact, when I look at the results of the XML merge in Tomcat's temp directory, the field seems to be defined:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101 https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101
Looking at the saved record at the API level, though, the field is not there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub now is close to the one that I found in the "HTML field level templates" documentation:
https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
Peter,
Aron's quite right -- dynamic lists load quickly, in practice. Indeed, any
performance issue encountered with dynamic lists is trivial when compared
with other performance issues often encountered in using CSpace. And the
benefit of not having to "engineer" changes in dropdowns -- priceless!
Good hunting!
John
On Tue, Sep 22, 2015 at 1:52 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
Thanks, John, for bringing up this important guidance! (As John notes, by
making the option list dynamic, users can edit its values themselves,
rather than requiring developer intervention to make even the slightest
changes.)
Peter, it's been my experience that dynamic option lists load quickly, in
practice. (This conceivably may in part be due to caching ...
https://wiki.collectionspace.org/display/DOC/Configuring+Caching+in+CollectionSpace
)
Geez! It was that easy? That seemed to do the trick. I wonder why it
(presumably!) works in other's code without that attribute ...
In the two examples you noted, it's possible both of these represented
instances of an existing field in the 'common' schema being overridden
(e.g. redefined) in a tenant-specific configuration file, rather than a new
field being added in an extension schema. (There are instances of fields in
extension schemas being added, elsewhere in those same configuration files,
and those do have the 'section=' attribute.)
On Tue, Sep 22, 2015 at 1:38 PM, Peter Murray pmurray@chillco.com wrote:
Thanks for the meta-observation, John. That would be my inclination,
too, but I remember hearing (somewhere) that there was a performance
penalty for dynamic lists. I imagine there is some database lookup time
involved, but I'm not far enough along to be able to quantify whether there
is a meaningful difference between static and dynamic lists. Any thoughts
on that would be most welcome.
Peter
On Sep 22, 2015, at 4:31 PM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
A "meta-observation" about the static list you are attempting to create.
We have found here at UCB that static lists are generally a bad idea: at
some point, users want to change or add values, and this then requires
"customization" -- a software engineer skilled in the art needs to make the
changes, commit them, redeploy CSpace, and then do any database updates
that might be required.
Far better, in general, to make all lists "dynamic" -- then users can
manage them on there own without engineering intervention.
There has been a lot of discussion about this, some of it here on this
Talk list, some of it in JIRAs. I'd be happy to track down some details for
you.
John
On Tue, Sep 22, 2015 at 1:26 PM, Aron Roberts <aron@socrates.berkeley.edu
wrote:
At first glance, what happens if you add the 'section="sdmom"'
attribute to the 'field' element for this new field, much as you did for
ownersRequirements?
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray pmurray@chillco.com
wrote:
Having figured out text fields (thanks again!), I'm now trying to add a
static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
UI DEFINITION
When I try to save the value in the field, it the UI just cycles back
to I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412]
Invalid input document. No such property was found [objectStatus] in schema
intakes_common
I am seeing the static fields in the pull-down list in the web UI.
Note also that I can save a value in the ownersRequirements text field in
the same extension. Based on those two factors, I'm pretty sure the
extension field definitions are getting merged into the config. In fact,
when I look at the results of the XML merge in Tomcat's temp directory,
the field seems to be defined:
Looking at the saved record at the API level, though, the field is not
there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub
now is close to the one that I found in the "HTML field level templates"
documentation:
--
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
And, as it happens, I ran across a ticket about from Mark from earlier this year:
[CSPACE-6620] Make all dropdown lists dynamic - CollectionSpace
I'm all on board with that. It looks like that'll be the path I take with the new lists that I'm creating.
Peter
On Sep 22, 2015, at 8:42 PM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
Aron's quite right -- dynamic lists load quickly, in practice. Indeed, any performance issue encountered with dynamic lists is trivial when compared with other performance issues often encountered in using CSpace. And the benefit of not having to "engineer" changes in dropdowns -- priceless!
Good hunting!
John
On Tue, Sep 22, 2015 at 1:52 PM, Aron Roberts <aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
Thanks, John, for bringing up this important guidance! (As John notes, by making the option list dynamic, users can edit its values themselves, rather than requiring developer intervention to make even the slightest changes.)
Peter, it's been my experience that dynamic option lists load quickly, in practice. (This conceivably may in part be due to caching ... https://wiki.collectionspace.org/display/DOC/Configuring+Caching+in+CollectionSpace https://wiki.collectionspace.org/display/DOC/Configuring+Caching+in+CollectionSpace)
Geez! It was that easy? That seemed to do the trick. I wonder why it (presumably!) works in other's code without that attribute ...
In the two examples you noted, it's possible both of these represented instances of an existing field in the 'common' schema being overridden (e.g. redefined) in a tenant-specific configuration file, rather than a new field being added in an extension schema. (There are instances of fields in extension schemas being added, elsewhere in those same configuration files, and those do have the 'section=' attribute.)
On Tue, Sep 22, 2015 at 1:38 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
Thanks for the meta-observation, John. That would be my inclination, too, but I remember hearing (somewhere) that there was a performance penalty for dynamic lists. I imagine there is some database lookup time involved, but I'm not far enough along to be able to quantify whether there is a meaningful difference between static and dynamic lists. Any thoughts on that would be most welcome.
Peter
On Sep 22, 2015, at 4:31 PM, John B. LOWE <jblowe@berkeley.edu mailto:jblowe@berkeley.edu> wrote:
Peter,
A "meta-observation" about the static list you are attempting to create.
We have found here at UCB that static lists are generally a bad idea: at some point, users want to change or add values, and this then requires "customization" -- a software engineer skilled in the art needs to make the changes, commit them, redeploy CSpace, and then do any database updates that might be required.
Far better, in general, to make all lists "dynamic" -- then users can manage them on there own without engineering intervention.
There has been a lot of discussion about this, some of it here on this Talk list, some of it in JIRAs. I'd be happy to track down some details for you.
John
On Tue, Sep 22, 2015 at 1:26 PM, Aron Roberts <aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
At first glance, what happens if you add the 'section="sdmom"' attribute to the 'field' element for this new field, much as you did for ownersRequirements?
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7
On Tue, Sep 22, 2015 at 1:21 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
Having figured out text fields (thanks again!), I'm now trying to add a static list field to a record. Here is the configuration I'm using:
RECORD EXTENSION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/application/sdmom-procedure-intake.xml#L7-L17
UI DEFINITION
https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51 https://github.com/cherryhill/sdmom-tenant-config/blob/SDMoM-52/ui/html/pages/IntakeTemplate.html#L44-L51
When I try to save the value in the field, it the UI just cycles back to I'm getting this error in cspace-services.log:
[org.collectionspace.services.common.document.DocumentUtils:1412] Invalid input document. No such property was found [objectStatus] in schema intakes_common
I am seeing the static fields in the pull-down list in the web UI. Note also that I can save a value in the ownersRequirements text field in the same extension. Based on those two factors, I'm pretty sure the extension field definitions are getting merged into the config. In fact, when I look at the results of the XML merge in Tomcat's temp directory, the field seems to be defined:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101 https://gist.github.com/dltj/aaa23d04188d791b78b1#file-merged-base-procedure-intake-xml_sdmom-procedure-intake-xml-xml-L91-L101
Looking at the saved record at the API level, though, the field is not there:
https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml https://gist.github.com/dltj/aaa23d04188d791b78b1#file-02b0b29c-5d23-4add-af50-xml
I've tried several variations with no success. The variation in GitHub now is close to the one that I found in the "HTML field level templates" documentation:
https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList https://wiki.collectionspace.org/display/DOC/HTML+field+level+templates#HTMLfieldleveltemplates-TermList
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company