Hi all, Is there a way to have a custom structured date field that varies depending on procedure type? For instance, I'd like to have a specific term list for a structured date instance (date association) in CollectionObject and other custom schema extensions. I'm thinking that adding in a section from base-other-structureddate.xml into {base/domain}-collectionobject.xml may work but maybe I'm not getting the syntax correct. Thoughts? - Jesse

                <field id="dateEarliestSingleCertainty" autocomplete="vocab-dateCertainty" ui-type="enum">
                    <selector>dateEarliestSingleCertainty</selector>
                    <preselector></preselector>
                </field>
                <field id="dateEarliestSingleQualifier">
                    <options>
                        <option id="+/-">+/-</option>
                        <option id="+">+</option>
                        <option id="-">-</option>
                    </options>
                    <selector>dateEarliestSingleQualifier</selector>
                    <preselector></preselector>
                </field>

                <field id="accessionDateGroup" ui-type="groupfield/structureddate" 
                    primarykey="accessionDateGroup.dateDisplayDate" ui-func="cspace.structuredDate2">
                </field>

Hi Jesse, You know how in base-other-structureddate.xml in the app layer, the structured date fields are defined, and options and autocomplete enums are specified? For example: <field id="dateEarliestSingleCertainty" autocomplete="vocab-dateCertainty" ui-type="enum"> <selector>dateEarliestSingleCertainty</selector> <preselector></preselector> </field> <field id="dateEarliestSingleQualifier"> <options> <option id="+/-">+/-</option> <option id="+">+</option> <option id="-">-</option> </options> <selector>dateEarliestSingleQualifier</selector> <preselector></preselector> </field> That's a giant red herring, because those options and autocomplete properties are never sent to the ui. They're just there to confuse you. Instead, they're defined for real in StructuredDate.js in the UI layer. See the cspace.structuredDate.popup.getProtoTree function. So, it sounds like most of your work will be in the UI. Ideally, you'd want to specify which structured date UI to use on a per-field basis. I believe the only way to do this currently would be to use the ui-func attribute in the app layer config. For example: <field id="accessionDateGroup" ui-type="groupfield/structureddate" primarykey="accessionDateGroup.dateDisplayDate" ui-func="cspace.structuredDate2"> </field> Note that I've changed ui-func from cspace.structuredDate to cspace.structuredDate2, which doesn't exist, but it could. Then it's a matter of getting a cspace.structuredDate2 component to be essentially a cspace.structuredDate component with different options, which is where it gets fuzzy for me. You'd need to change the popup subcomponent's getProtoTree option to point to your own function, and the popup subcomponent's resources.template.url option to point to your own template. Yura, if you're reading this, does this sound like it's on the right track? Hope this sort of helps, anyway! Ray On Jun 6, 2012, at 8:25 AM, Jesse Martinez wrote: > Hi all, > > Is there a way to have a custom structured date field that varies > depending on procedure type? For instance, I'd like to have a specific > term list for a structured date instance (date association) in > CollectionObject and other custom schema extensions. I'm thinking that > adding in a section from base-other-structureddate.xml into > {base/domain}-collectionobject.xml may work but maybe I'm not getting > the syntax correct. > > Thoughts? > > - Jesse > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Thanks for your tip, Ray! >From what I can tell, this is a correct approach to customizing a non-standard structured date instance. I created a new component, cspace.workStructuredDate, and defined all respective functions and properties within StructuredDate.js -- basically by copy/pasting the original cspace.structuredDate component. This can certainly be refactored, but it's fairly straightforward setting up; although, having multiple structured date instances may make maintenance a bit fuzzy. I then attached this component to the specific field with the ui-func attribute and it works... mostly. I can't get the structured date to save properly. The dropdowns save but not the free text fields. Thoughts about this, Yura? - Jesse On Wed, Jun 6, 2012 at 4:14 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Jesse, > You know how in base-other-structureddate.xml in the app layer, the > structured date fields are defined, and options and autocomplete enums are > specified? For example: > >                     <field id="dateEarliestSingleCertainty" > autocomplete="vocab-dateCertainty" ui-type="enum"> >                         <selector>dateEarliestSingleCertainty</selector> >                         <preselector></preselector> >                     </field> >                     <field id="dateEarliestSingleQualifier"> >                         <options> >                             <option id="+/-">+/-</option> >                             <option id="+">+</option> >                             <option id="-">-</option> >                         </options> >                         <selector>dateEarliestSingleQualifier</selector> >                         <preselector></preselector> >                     </field> > > That's a giant red herring, because those options and autocomplete > properties are never sent to the ui. They're just there to confuse you. > Instead, they're defined for real in StructuredDate.js in the UI layer. See > the cspace.structuredDate.popup.getProtoTree function. > > So, it sounds like most of your work will be in the UI. Ideally, you'd want > to specify which structured date UI to use on a per-field basis. I believe > the only way to do this currently would be to use the ui-func attribute in > the app layer config. For example: > >                     <field id="accessionDateGroup" > ui-type="groupfield/structureddate" >                         primarykey="accessionDateGroup.dateDisplayDate" > ui-func="cspace.structuredDate2"> >                     </field> > > Note that I've changed ui-func from cspace.structuredDate to > cspace.structuredDate2, which doesn't exist, but it could. Then it's a > matter of getting a cspace.structuredDate2 component to be essentially a > cspace.structuredDate component with different options, which is where it > gets fuzzy for me. You'd need to change the popup subcomponent's > getProtoTree option to point to your own function, and the popup > subcomponent's resources.template.url option to point to your own template. > > Yura, if you're reading this, does this sound like it's on the right track? > > Hope this sort of helps, anyway! > > Ray > > > > On Jun 6, 2012, at 8:25 AM, Jesse Martinez wrote: > > Hi all, > > Is there a way to have a custom structured date field that varies > depending on procedure type? For instance, I'd like to have a specific > term list for a structured date instance (date association) in > CollectionObject and other custom schema extensions. I'm thinking that > adding in a section from base-other-structureddate.xml into > {base/domain}-collectionobject.xml may work but maybe I'm not getting > the syntax correct. > > Thoughts? > > - Jesse > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

                 <field id="dateEarliestSingleCertainty"

                 <field id="accessionDateGroup"

One of our deployments just asked for basically this, so I'm glad it came up. I feel like there must be some way to do it without copying the entire StructuredDate.js -- just overriding the parts that you need to change, but I'm not fluent enough in Infusion. Ray On Jun 14, 2012, at 1:32 PM, Jesse Martinez wrote: > Thanks for your tip, Ray! > > From what I can tell, this is a correct approach to customizing a > non-standard structured date instance. I created a new component, > cspace.workStructuredDate, and defined all respective functions and > properties within StructuredDate.js -- basically by copy/pasting the > original cspace.structuredDate component. This can certainly be > refactored, but it's fairly straightforward setting up; although, > having multiple structured date instances may make maintenance a bit > fuzzy. > I then attached this component to the specific field with the ui-func > attribute and it works... mostly. I can't get the structured date to > save properly. The dropdowns save but not the free text fields. > Thoughts about this, Yura? > > - Jesse > > > > On Wed, Jun 6, 2012 at 4:14 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> Hi Jesse, >> You know how in base-other-structureddate.xml in the app layer, the >> structured date fields are defined, and options and autocomplete enums are >> specified? For example: >> >> <field id="dateEarliestSingleCertainty" >> autocomplete="vocab-dateCertainty" ui-type="enum"> >> <selector>dateEarliestSingleCertainty</selector> >> <preselector></preselector> >> </field> >> <field id="dateEarliestSingleQualifier"> >> <options> >> <option id="+/-">+/-</option> >> <option id="+">+</option> >> <option id="-">-</option> >> </options> >> <selector>dateEarliestSingleQualifier</selector> >> <preselector></preselector> >> </field> >> >> That's a giant red herring, because those options and autocomplete >> properties are never sent to the ui. They're just there to confuse you. >> Instead, they're defined for real in StructuredDate.js in the UI layer. See >> the cspace.structuredDate.popup.getProtoTree function. >> >> So, it sounds like most of your work will be in the UI. Ideally, you'd want >> to specify which structured date UI to use on a per-field basis. I believe >> the only way to do this currently would be to use the ui-func attribute in >> the app layer config. For example: >> >> <field id="accessionDateGroup" >> ui-type="groupfield/structureddate" >> primarykey="accessionDateGroup.dateDisplayDate" >> ui-func="cspace.structuredDate2"> >> </field> >> >> Note that I've changed ui-func from cspace.structuredDate to >> cspace.structuredDate2, which doesn't exist, but it could. Then it's a >> matter of getting a cspace.structuredDate2 component to be essentially a >> cspace.structuredDate component with different options, which is where it >> gets fuzzy for me. You'd need to change the popup subcomponent's >> getProtoTree option to point to your own function, and the popup >> subcomponent's resources.template.url option to point to your own template. >> >> Yura, if you're reading this, does this sound like it's on the right track? >> >> Hope this sort of helps, anyway! >> >> Ray >> >> >> >> On Jun 6, 2012, at 8:25 AM, Jesse Martinez wrote: >> >> Hi all, >> >> Is there a way to have a custom structured date field that varies >> depending on procedure type? For instance, I'd like to have a specific >> term list for a structured date instance (date association) in >> CollectionObject and other custom schema extensions. I'm thinking that >> adding in a section from base-other-structureddate.xml into >> {base/domain}-collectionobject.xml may work but maybe I'm not getting >> the syntax correct. >> >> Thoughts? >> >> - Jesse >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >>

                 <field id="dateEarliestSingleCertainty"

                 <field id="accessionDateGroup"

Just a small update. It appears that it is necessary to add in a fluid.demands block in Demands.js (around line 2123 in v2.4) for the custom component made in StructuredDate.js This will allow the UI the populate the values into the text fields in the structured date widget. - Jesse On Fri, Jun 15, 2012 at 2:21 PM, Ray Lee <rhlee@berkeley.edu> wrote: > One of our deployments just asked for basically this, so I'm glad it came up. I feel like there must be some way to do it without copying the entire StructuredDate.js -- just overriding the parts that you need to change, but I'm not fluent enough in Infusion. > > Ray > > > On Jun 14, 2012, at 1:32 PM, Jesse Martinez wrote: > >> Thanks for your tip, Ray! >> >> From what I can tell, this is a correct approach to customizing a >> non-standard structured date instance. I created a new component, >> cspace.workStructuredDate, and defined all respective functions and >> properties within StructuredDate.js -- basically by copy/pasting the >> original cspace.structuredDate component. This can certainly be >> refactored, but it's fairly straightforward setting up; although, >> having multiple structured date instances may make maintenance a bit >> fuzzy. >> I then attached this component to the specific field with the ui-func >> attribute and it works... mostly. I can't get the structured date to >> save properly. The dropdowns save but not the free text fields. >> Thoughts about this, Yura? >> >> - Jesse >> >> >> >> On Wed, Jun 6, 2012 at 4:14 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>> Hi Jesse, >>> You know how in base-other-structureddate.xml in the app layer, the >>> structured date fields are defined, and options and autocomplete enums are >>> specified? For example: >>> >>> <field id="dateEarliestSingleCertainty" >>> autocomplete="vocab-dateCertainty" ui-type="enum"> >>> <selector>dateEarliestSingleCertainty</selector> >>> <preselector></preselector> >>> </field> >>> <field id="dateEarliestSingleQualifier"> >>> <options> >>> <option id="+/-">+/-</option> >>> <option id="+">+</option> >>> <option id="-">-</option> >>> </options> >>> <selector>dateEarliestSingleQualifier</selector> >>> <preselector></preselector> >>> </field> >>> >>> That's a giant red herring, because those options and autocomplete >>> properties are never sent to the ui. They're just there to confuse you. >>> Instead, they're defined for real in StructuredDate.js in the UI layer. See >>> the cspace.structuredDate.popup.getProtoTree function. >>> >>> So, it sounds like most of your work will be in the UI. Ideally, you'd want >>> to specify which structured date UI to use on a per-field basis. I believe >>> the only way to do this currently would be to use the ui-func attribute in >>> the app layer config. For example: >>> >>> <field id="accessionDateGroup" >>> ui-type="groupfield/structureddate" >>> primarykey="accessionDateGroup.dateDisplayDate" >>> ui-func="cspace.structuredDate2"> >>> </field> >>> >>> Note that I've changed ui-func from cspace.structuredDate to >>> cspace.structuredDate2, which doesn't exist, but it could. Then it's a >>> matter of getting a cspace.structuredDate2 component to be essentially a >>> cspace.structuredDate component with different options, which is where it >>> gets fuzzy for me. You'd need to change the popup subcomponent's >>> getProtoTree option to point to your own function, and the popup >>> subcomponent's resources.template.url option to point to your own template. >>> >>> Yura, if you're reading this, does this sound like it's on the right track? >>> >>> Hope this sort of helps, anyway! >>> >>> Ray >>> >>> >>> >>> On Jun 6, 2012, at 8:25 AM, Jesse Martinez wrote: >>> >>> Hi all, >>> >>> Is there a way to have a custom structured date field that varies >>> depending on procedure type? For instance, I'd like to have a specific >>> term list for a structured date instance (date association) in >>> CollectionObject and other custom schema extensions. I'm thinking that >>> adding in a section from base-other-structureddate.xml into >>> {base/domain}-collectionobject.xml may work but maybe I'm not getting >>> the syntax correct. >>> >>> Thoughts? >>> >>> - Jesse >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >