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

Hi Chad, Structured date fields might be a good example. Ray On Tue, Sep 8, 2015 at 11:28 AM, 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 >

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 >

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