talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsRemoving or renaming the Dimensions Service [was Re: Advice on reusable filed groups for Transport Extension]
Ray wrote:
I'm guessing the dimension service could be removed without any effect,
and it probably should be, so that there is no longer confusion about this.
+1. The continued existence of the Dimensions service is unfortunate and
confusing.
However, vestigial and/or obsolete components sometimes become
dependencies, inadvertently or otherwise, and Dimensions is one of them. At
least three or four Services tests use Dimensions (see list below),
presumably because it was an otherwise unused service and thus a convenient
place to point those tests. So we'll need to take those tests into account
before removing it.
As one possible alternative to removing the Dimensions service, Richard
created this JIRA to rename that service, to change it to a generic service
for testing purposes:
https://issues.collectionspace.org/browse/CSPACE-3738
Aron
--
(using ack: http://beyondgrep.com/)
$ ack -l dimension | grep -v target | grep -i test
...
services/IntegrationTests/pom.xml
services/IntegrationTests/src/main/java/org/collectionspace/services/IntegrationTests/xmlreplay/XmlReplayTest.java
services/IntegrationTests/src/test/java/org/collectionspace/services/IntegrationTests/test/RelationIntegrationTest.java
services/IntegrationTests/src/test/java/org/collectionspace/services/IntegrationTests/test/XmlReplaySelfTest.java
services/IntegrationTests/src/test/resources/test-data/xmlreplay/collectionobject/nh-collectionobject.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/dimension/1.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/dimension/2-put.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/dimension-master.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/dimension.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/imports/import-objectexit-media.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/location/hierarchy/0-note.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/location/location-hierarchy-dual-parents.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/1-bigbird-permission.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/10-permissionroles-elmo.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/11-bigbird-permission-CRU.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/11-permissionroles-bigbird-CRU.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/12-bigbird-permission-R.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/12-permissionroles-bigbird-R.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/13-permissionroles-bigbird.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/2-elmo-permission.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/9-permissionroles-bigbird.xml
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security/Base64-authentication-notes.txt
services/IntegrationTests/src/test/resources/test-data/xmlreplay/security.xml
services/security/client/src/test/java/org/collectionspace/services/security/client/test/AuthorizationServiceTest.java
services/security/client/src/test/java/org/collectionspace/services/security/client/test/MultiTenancyTest.java
services/workflow/client/src/test/java/org/collectionspace/services/client/test/WorkflowServiceTest.java
On Tue, Nov 3, 2015 at 4:09 PM, Ray Lee rhlee@berkeley.edu wrote:
I just had to do this. Here's what I found.
tl;dr: Use dimensions as an example.
There is a misconception about dimensions. While there is code in the
services layer that establishes a dimension service, it does not appear
that dimension records are ever created. The dimension fields appear
directly in the schemas of the records that incorporate them
(collectionobject and media). That makes dimensions similar to structured
dates, both of which are suitable examples to use for what Chad wanted to
do. I'm guessing the dimension service could be removed without any effect,
and it probably should be, so that there is no longer confusion about this.
Dimensions and structured dates look like records in app layer config, but
really they are definitions of complex types, which can then be used (and
reused) when defining fields in actual records.
In contrast to this, the contact information fields that appear in person
and organization records are actually distinct record types, handled by
their own service. I haven't looked into how you might replicate this with
your own record type, but I suspect that it would be difficult, and may
require writing services layer code. I'm not sure why contacts are treated
differently than dimensions and structured dates. One possibility is that
being a record type means that the contact information schema can be
extended with local fields. (I'm not sure if this actually works.) Since
dimensions and structured dates are not really records, there is no
apparatus for extending them. A disadvantage of the way contacts are
modeled is that search doesn't work as you'd expect:
https://issues.collectionspace.org/browse/CSPACE-5604
Using dimensions as an example I was able to get my own shared complex
type working, but I ran into some issues with generating services
artifacts. First, if your complex type includes a structured date field,
the services schemas won't be generated correctly. Also, if your complex
type includes fields tied to authorities or dynamic term lists, and you use
that complex type in an extension schema (i.e. not the common schema), the
services bindings will not be generated correctly (the authref and termref
configurations will be in the wrong place). I put in some slightly hacky
fixes to these issues on the UCB branch. Details are here:
https://issues.collectionspace.org/browse/UCJEPS-619
Ray
On Wed, Sep 9, 2015 at 8:24 AM, Jesse Martinez mjesse@gmail.com wrote:
Hi Chad,
I don't think I've personally experienced adding a single extension
across multiple procedures. It might work well to extend each procedure as
it can become a standard example for implementors for extending multiple
procedures with a single extension set. It might not be the most efficient
way to handle this but I can see a benefit of not needing to build
extensive services layer code.
Just my two cents.
Jesse
On Tue, Sep 8, 2015 at 2:28 PM, Chad Nelson chad.nelson@lyrasis.org
wrote:
Hi All,
As part of my work on 4.3, I'm working on the Local History and
Material Culture Extension
https://wiki.collectionspace.org/display/collectionspace/Local+History+and+Material+Culture+Extension+Set+-+DRAFT
set, which includes the Transport extension
https://wiki.collectionspace.org/display/collectionspace/Transport+Extension+Review+and+Comment+Page+-+LHMC,
which is a group of fields describing an objects transport from one
location to another which "may be added to any relevant procedure, such
as Loans In or Out, Deaccession and Disposal, or Intake".
In trying to understand how to implement this, I started looking at the
way Dimensions group is set up in the Collection Object / Cataloging
config and component templates. However, Richard thought this might not be
the best example to follow because Dimension has a Services layer service
behind it, which he thinks will be overkill for this.
While I could simply extend each procedure that needs these extra
fields, it feels like it would be more efficient and easier to configure if
every procedure implementing Transport used the some database table and
HTML
Anyone else have experience implementing a group of fields intended to
be used across procedures or have some code you can point me towards that
would provide a good example of how this can be implemented.
Thanks,
Chad
To add to this talk about being confusing, I've burned quite a number of hours trying to extend the Dimensions area of the collectionobject record to include a new repeatable group and replace the static term lists with dynamic ones (https://github.com/cherryhill/sdmom-tenant-config/blob/3d46466cc650dfb0aea7fc24c7c9bb61d3f2eccf/application/sdmom-other-dimension.xml#L20-L27 https://github.com/cherryhill/sdmom-tenant-config/blob/3d46466cc650dfb0aea7fc24c7c9bb61d3f2eccf/application/sdmom-other-dimension.xml#L20-L27), and I could just never get it to work. There were these really odd-ball effects were some of the fields would be stored in the database record while others weren't, and some of the dynamic term lists would populate while others wouldn't. Finally I decide to punt on the whole thing and just embed the dimensions schema into the collectionobject schema and adjust the CatalogingTemplate. But if a some sort of dimensions record isn't included in the application-tenant.xml file, then CSpace crashes on launch with a very unhelpful traceback:
SEVERE: Servlet.service() for servlet [TenantUIServlet] in context with path [/collectionspace] threw exception
java.lang.NullPointerException
at org.collectionspace.chain.csp.schema.Record.findDisplayNameField(Record.java:1070)
at org.collectionspace.chain.csp.schema.Record.config_finish(Record.java:1324)
at org.collectionspace.chain.csp.schema.Spec.config_finish(Spec.java:528)
at org.collectionspace.csp.container.impl.CSPManagerImpl.configure(CSPManagerImpl.java:79)
at org.collectionspace.chain.controller.TenantServlet.load_config(TenantServlet.java:156)
at org.collectionspace.chain.controller.TenantServlet.setup(TenantServlet.java:179)
at org.collectionspace.chain.controller.TenantUIServlet.serviceUIWTenant(TenantUIServlet.java:117)
at org.collectionspace.chain.controller.TenantUIServlet.service(TenantUIServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
...
I looked at a couple of Jira issues before going down this path:
[CSPACE-6397] Nuxeo artifacts are not generated for dimensions - CollectionSpace
[CSPACE-6398] Dimensions service bindings are not generated from app layer config - CollectionSpace
But those seemed even more complicated. In the end, it seems like hiding the base-supplied div controlling the display in the UI of the dimensions pseudo-record-type seemed like the path of least resistance (https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L905 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L905). I've effectively rebuilt the base-other-dimensions.xml definition inside blah-collectionobject.xml and recreated the GUI template definition.
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/application/sdmom-collectionobject.xml#L250-L266 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/application/sdmom-collectionobject.xml#L250-L266
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/html/pages/CatalogingTemplate.html#L468-L561 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/html/pages/CatalogingTemplate.html#L468-L561
Yet although values are getting stored in the database, I can't get the labels to appear:
The "Audio/Visual Information" label is drawn, but I have to use a seemingly odd repeated-group-within-repeated-group selector to get it to work. The three labels at the top are never drawn, whether I'm using the standard "collection-object-*Label" selector or the repeated group selector.
Full generated source --> https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1026-L1433 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1026-L1433
Lines for the three missing labels and where they are defined in core-messages.properties-overlay:
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1037 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1037
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L148 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L148
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1071 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1071
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L151 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L151
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L153 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L153
...and the odd duck:
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L155 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L155
Peter
On Nov 13, 2015, at 5:33 PM, Aron Roberts aron@socrates.berkeley.edu wrote:
Ray wrote:
I'm guessing the dimension service could be removed without any effect, and it probably should be, so that there is no longer confusion about this.
+1. The continued existence of the Dimensions service is unfortunate and confusing.
However, vestigial and/or obsolete components sometimes become dependencies, inadvertently or otherwise, and Dimensions is one of them. At least three or four Services tests use Dimensions (see list below), presumably because it was an otherwise unused service and thus a convenient place to point those tests. So we'll need to take those tests into account before removing it.
As one possible alternative to removing the Dimensions service, Richard created this JIRA to rename that service, to change it to a generic service for testing purposes:
https://issues.collectionspace.org/browse/CSPACE-3738 https://issues.collectionspace.org/browse/CSPACE-3738
Aron
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
Hi Peter,
The repeated-group-within-repeated-group selector is normal. I just go with
it.
For the dimPartVersion label that's not drawn, the problem there is that
there's nothing in the app layer config called dimPartVersion. You would
think that you could just make up any class name in the HTML template, and
put a corresponding message key in the message bundle, but that's not the
case. The allowable message keys are actually generated from the app layer
config. For situations like this, where you need a message bundle entry for
some random text in the UI that doesn't correspond to a field or field
group, there's a hack: create an empty <section>. Sections have message
keys generated for them, so you can use that key for your text. There's an
example in movement:
https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-procedure-movement.xml#L57
For dimMeasuredPartGroup, I'm guessing it should be
csc-dimMeasuredPartGroup-dimSubGroup-label, because you have
csc-dimMeasuredPartGroup-dimSubGroup, and that saves. So appending -label
to that should give you the correct label class.
For dimValue you might just need to change the case of the class? You have
dimvalue.
Ray
On Fri, Nov 27, 2015 at 8:02 PM, Peter Murray pmurray@chillco.com wrote:
To add to this talk about being confusing, I've burned quite a number of
hours trying to extend the Dimensions area of the collectionobject record
to include a new repeatable group and replace the static term lists with
dynamic ones (
https://github.com/cherryhill/sdmom-tenant-config/blob/3d46466cc650dfb0aea7fc24c7c9bb61d3f2eccf/application/sdmom-other-dimension.xml#L20-L27),
and I could just never get it to work. There were these really odd-ball
effects were some of the fields would be stored in the database record
while others weren't, and some of the dynamic term lists would populate
while others wouldn't. Finally I decide to punt on the whole thing and
just embed the dimensions schema into the collectionobject schema and
adjust the CatalogingTemplate. But if a some sort of dimensions record
isn't included in the application-tenant.xml file, then CSpace crashes on
launch with a very unhelpful traceback:
SEVERE: Servlet.service() for servlet [TenantUIServlet] in context with
path [/collectionspace] threw exception
java.lang.NullPointerException
at
org.collectionspace.chain.csp.schema.Record.findDisplayNameField(Record.java:1070)
at
org.collectionspace.chain.csp.schema.Record.config_finish(Record.java:1324)
at
org.collectionspace.chain.csp.schema.Spec.config_finish(Spec.java:528)
at
org.collectionspace.csp.container.impl.CSPManagerImpl.configure(CSPManagerImpl.java:79)
at
org.collectionspace.chain.controller.TenantServlet.load_config(TenantServlet.java:156)
at
org.collectionspace.chain.controller.TenantServlet.setup(TenantServlet.java:179)
at
org.collectionspace.chain.controller.TenantUIServlet.serviceUIWTenant(TenantUIServlet.java:117)
at
org.collectionspace.chain.controller.TenantUIServlet.service(TenantUIServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
...
I looked at a couple of Jira issues before going down this path:
[CSPACE-6397] Nuxeo artifacts are not generated for dimensions -
CollectionSpace
[CSPACE-6398] Dimensions service bindings are not generated from app
layer config - CollectionSpace
But those seemed even more complicated. In the end, it seems like hiding
the base-supplied div controlling the display in the UI of the dimensions
pseudo-record-type seemed like the path of least resistance (
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L905).
I've effectively rebuilt the base-other-dimensions.xml definition inside
blah-collectionobject.xml and recreated the GUI template definition.
Yet although values are getting stored in the database, I can't get the
labels to appear:
The "Audio/Visual Information" label is drawn, but I have to use a
seemingly odd repeated-group-within-repeated-group selector to get it to
work. The three labels at the top are never drawn, whether I'm using the
standard "collection-object-*Label" selector or the repeated group selector.
Full generated source -->
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1026-L1433
Lines for the three missing labels and where they are defined in
core-messages.properties-overlay:
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1037
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1071
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078
...and the odd duck:
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078
Peter
On Nov 13, 2015, at 5:33 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
Ray wrote:
I'm guessing the dimension service could be removed without any effect,
and it probably should be, so that there is no longer confusion about this.
+1. The continued existence of the Dimensions service is unfortunate and
confusing.
However, vestigial and/or obsolete components sometimes become
dependencies, inadvertently or otherwise, and Dimensions is one of them. At
least three or four Services tests use Dimensions (see list below),
presumably because it was an otherwise unused service and thus a convenient
place to point those tests. So we'll need to take those tests into account
before removing it.
As one possible alternative to removing the Dimensions service, Richard
created this JIRA to rename that service, to change it to a generic service
for testing purposes:
https://issues.collectionspace.org/browse/CSPACE-3738
Aron
--
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
Oh, interesting -- generating the labels is more complicated than I thought. The empty <section> tag sounds like a good solution. And you pointed out the problem with the capitalization in dimvalue -- thanks for that. I'll dig back into the application and UI config to make sure I have everything synced up.
Peter
On Dec 2, 2015, at 12:28 AM, Ray Lee rhlee@berkeley.edu wrote:
Hi Peter,
The repeated-group-within-repeated-group selector is normal. I just go with it.
For the dimPartVersion label that's not drawn, the problem there is that there's nothing in the app layer config called dimPartVersion. You would think that you could just make up any class name in the HTML template, and put a corresponding message key in the message bundle, but that's not the case. The allowable message keys are actually generated from the app layer config. For situations like this, where you need a message bundle entry for some random text in the UI that doesn't correspond to a field or field group, there's a hack: create an empty <section>. Sections have message keys generated for them, so you can use that key for your text. There's an example in movement: https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-procedure-movement.xml#L57 https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/defaults/base-procedure-movement.xml#L57
For dimMeasuredPartGroup, I'm guessing it should be csc-dimMeasuredPartGroup-dimSubGroup-label, because you have csc-dimMeasuredPartGroup-dimSubGroup, and that saves. So appending -label to that should give you the correct label class.
For dimValue you might just need to change the case of the class? You have dimvalue.
Ray
On Fri, Nov 27, 2015 at 8:02 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
To add to this talk about being confusing, I've burned quite a number of hours trying to extend the Dimensions area of the collectionobject record to include a new repeatable group and replace the static term lists with dynamic ones (https://github.com/cherryhill/sdmom-tenant-config/blob/3d46466cc650dfb0aea7fc24c7c9bb61d3f2eccf/application/sdmom-other-dimension.xml#L20-L27 https://github.com/cherryhill/sdmom-tenant-config/blob/3d46466cc650dfb0aea7fc24c7c9bb61d3f2eccf/application/sdmom-other-dimension.xml#L20-L27), and I could just never get it to work. There were these really odd-ball effects were some of the fields would be stored in the database record while others weren't, and some of the dynamic term lists would populate while others wouldn't. Finally I decide to punt on the whole thing and just embed the dimensions schema into the collectionobject schema and adjust the CatalogingTemplate. But if a some sort of dimensions record isn't included in the application-tenant.xml file, then CSpace crashes on launch with a very unhelpful traceback:
SEVERE: Servlet.service() for servlet [TenantUIServlet] in context with path [/collectionspace] threw exception
java.lang.NullPointerException
at org.collectionspace.chain.csp.schema.Record.findDisplayNameField(Record.java:1070)
at org.collectionspace.chain.csp.schema.Record.config_finish(Record.java:1324)
at org.collectionspace.chain.csp.schema.Spec.config_finish(Spec.java:528)
at org.collectionspace.csp.container.impl.CSPManagerImpl.configure(CSPManagerImpl.java:79)
at org.collectionspace.chain.controller.TenantServlet.load_config(TenantServlet.java:156)
at org.collectionspace.chain.controller.TenantServlet.setup(TenantServlet.java:179)
at org.collectionspace.chain.controller.TenantUIServlet.serviceUIWTenant(TenantUIServlet.java:117)
at org.collectionspace.chain.controller.TenantUIServlet.service(TenantUIServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
...
I looked at a couple of Jira issues before going down this path:
[[CSPACE-6397] Nuxeo artifacts are not generated for dimensions - CollectionSpace](https://issues.collectionspace.org/browse/CSPACE-6397 https://issues.collectionspace.org/browse/CSPACE-6397)
[[CSPACE-6398] Dimensions service bindings are not generated from app layer config - CollectionSpace](https://issues.collectionspace.org/browse/CSPACE-6398 https://issues.collectionspace.org/browse/CSPACE-6398)
But those seemed even more complicated. In the end, it seems like hiding the base-supplied div controlling the display in the UI of the dimensions pseudo-record-type seemed like the path of least resistance (https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L905 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L905). I've effectively rebuilt the base-other-dimensions.xml definition inside blah-collectionobject.xml and recreated the GUI template definition.
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/application/sdmom-collectionobject.xml#L250-L266 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/application/sdmom-collectionobject.xml#L250-L266
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/html/pages/CatalogingTemplate.html#L468-L561 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/html/pages/CatalogingTemplate.html#L468-L561
Yet although values are getting stored in the database, I can't get the labels to appear:
<PastedGraphic-1.tiff>
The "Audio/Visual Information" label is drawn, but I have to use a seemingly odd repeated-group-within-repeated-group selector to get it to work. The three labels at the top are never drawn, whether I'm using the standard "collection-object-*Label" selector or the repeated group selector.
Full generated source --> https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1026-L1433 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1026-L1433
Lines for the three missing labels and where they are defined in core-messages.properties-overlay:
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1037 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1037
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L148 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L148
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1071 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1071
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L151 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L151
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L153 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L153
...and the odd duck:
https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078 https://gist.github.com/dltj/2b552238aae163cf99e1#file-cataloging-html-L1078
https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L155 https://github.com/cherryhill/sdmom-tenant-config/blob/dc9a5f27cb502b525bdec17b8ac1ff944d68b2b0/ui/bundle/core-messages.properties-overlay#L155
Peter
On Nov 13, 2015, at 5:33 PM, Aron Roberts <aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
Ray wrote:
I'm guessing the dimension service could be removed without any effect, and it probably should be, so that there is no longer confusion about this.
+1. The continued existence of the Dimensions service is unfortunate and confusing.
However, vestigial and/or obsolete components sometimes become dependencies, inadvertently or otherwise, and Dimensions is one of them. At least three or four Services tests use Dimensions (see list below), presumably because it was an otherwise unused service and thus a convenient place to point those tests. So we'll need to take those tests into account before removing it.
As one possible alternative to removing the Dimensions service, Richard created this JIRA to rename that service, to change it to a generic service for testing purposes:
https://issues.collectionspace.org/browse/CSPACE-3738 https://issues.collectionspace.org/browse/CSPACE-3738
Aron
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company