Hi Sébastien,
I think what you're trying to do is going to end up being quite complex, so you haven't missed anything. In the services layer, I think you're right to create a new complex type (structuredDateGroupSMK) in your local schema. The structuredDateGroupSMK type would be identical to structuredDateGroup from the common schema, except for the addition of your new field (dateSMKDisplayText). You won't be able to change existing fields in the common schema to be structuredDateGroupSMK instead of structuredDateGroup. You'll have to create new fields in the local schema that have type structuredDateGroupSMK, and use these new fields as replacements for the ones in the common schema.

As a first step, I would create a new field of type structuredDateGroupSMK in your local schema, and use the REST API to read and write that field. Then you'll know that the services layer is configured properly. Then you can move on to the app layer. I'm not sure if you can make this work entirely through xml configuration. This may require modification to the app layer's java code, because there's some special handling for structured dates in there.

The lifesci tenant is using a new (as of 2.3) way of configuring the app layer that potentially makes things easier, but you don't have to use it. The way you've been doing it still works. The new app layer merge stuff really needs to get documented.

If you get the services layer working, let us know. I might be able to help more with the app layer.

Thanks,
Ray

On Jul 23, 2012, at 1:13 AM, Sébastien Brossard wrote:

Ray wrote:

Agreed completely, Ray.  These's a JIRA issue to begin documenting this:
http://issues.collectionspace.org/browse/CSPACE-5070

This should get done in either the Doc5 sprint (currently ongoing) or if
not by then, by no later than the next one (Doc6); it's a huge priority.

Aron

On Tue, Jul 24, 2012 at 3:52 PM, Ray Lee rhlee@berkeley.edu wrote:

As to the app layer support for structured dates, it should actually work
okay. The tenant override will inject the new field(s) into the
base-other-structureddate definition. It is a sub-record, so it is actually
somewhat more flexible in some ways that other repeating groups. I think
that the app layer logic will be okay if you just add fields.

You may have to change the way you declare it when it occurs in other
records, but we'll cross that bridge we get to it.

As Ray says, get the services working, and we'll help from there.

Patrick

From: talk-bounces@lists.collectionspace.org
[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Aron Roberts
Sent: Tuesday, July 24, 2012 4:39 PM
To: Ray Lee
Cc: talk@lists.collectionspace.org; Sébastien Brossard
Subject: Re: [Talk] Local Schema Extension: adding a new xs:element
inxs:complexType

Ray wrote:

Agreed completely, Ray.  These's a JIRA issue to begin documenting this:
http://issues.collectionspace.org/browse/CSPACE-5070

This should get done in either the Doc5 sprint (currently ongoing) or if not
by then, by no later than the next one (Doc6); it's a huge priority.

Aron

On Tue, Jul 24, 2012 at 3:52 PM, Ray Lee rhlee@berkeley.edu wrote:

Hi Sébastien,
I think what you're trying to do is going to end up being quite complex, so
you haven't missed anything. In the services layer, I think you're right to
create a new complex type (structuredDateGroupSMK) in your local schema. The
structuredDateGroupSMK type would be identical to structuredDateGroup from
the common schema, except for the addition of your new field
(dateSMKDisplayText). You won't be able to change existing fields in the
common schema to be structuredDateGroupSMK instead of structuredDateGroup.
You'll have to create new fields in the local schema that have type
structuredDateGroupSMK, and use these new fields as replacements for the
ones in the common schema.

As a first step, I would create a new field of type structuredDateGroupSMK
in your local schema, and use the REST API to read and write that field.
Then you'll know that the services layer is configured properly. Then you
can move on to the app layer. I'm not sure if you can make this work
entirely through xml configuration. This may require modification to the app
layer's java code, because there's some special handling for structured
dates in there.

The lifesci tenant is using a new (as of 2.3) way of configuring the app
layer that potentially makes things easier, but you don't have to use it.
The way you've been doing it still works. The new app layer merge stuff
really needs to get documented.

If you get the services layer working, let us know. I might be able to help
more with the app layer.

Thanks,
Ray

On Jul 23, 2012, at 1:13 AM, Sébastien Brossard wrote:

Dear all,
I’m currently trying to add some customized fields in the frame of SMK’s
Local Schema Extension.

As a first try, I could successfully add a new xs:element in the
domain-collectionobject,
(I added two files in SMK’s tenant:

• services/…/ nuxeo-platform-collectionobject-smk/…/shemas/
  collectionobjects_smk.xsd
• application/…/tenant/smk/ domain-collectionobject.xml

• modified my ui so that to show my new field. It worked fine, showed and
  saved field’s value.)

But here it’s a bit more complex : I would like to add some fields in the
StructuredDate component.

More precisely, I want to add a new xs:element (dateSMKDisplayText) in
<xs:complexType name="structuredDateGroup">

·        I tried by many many ways to add my new element in the existing
structuredDateGroup via SMK’s tenant, without any success.

·        Looking at the lifesci example, I tried to create a new complex
type “structuredDateGroupSMK” (which means that I had to create a new
xs:element who supports this new complex type ), but:

o  In lifesci-tenant.xml there’s a merging function that I don’t know
nothing about (<include src="base-collectionobject.xml,naturalhistory-collectionobject.xml" merge="xmlmerge.properties"/>), which confused me.
o  structuredDateGroup is used in many places in the code, which means that
I should replace it in numerous places in the code – which I think is not a
brilliant idea.

It seems a bit too much complex, so I suppose I missed a simpler way to
achieve this.

Thank you by advance for your kindly help and tips.

Best regards,
Sébastien

Sébastien Brossard
IT-Udvikler
mailto:3sebastien.brossard@smk.dkT sebastien.brossard@smk.dk
mailto:3sebastien.brossard@smk.dkT T +45 3374 8483
tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK—1307 København K
T +45  tel:%2B45%203374%208494 3374 8494
F +45  tel:%2B45%203374%208404 3374 8404
http://smk.dk/ smk.dk

<image004.jpg>

Sébastien Brossard
IT-Udvikler
mailto:3sebastien.brossard@smk.dkT sebastien.brossard@smk.dk
mailto:3sebastien.brossard@smk.dkT T +45 3374 8483
tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK—1307 København K
T +45  tel:%2B45%203374%208494 3374 8494
F +45  tel:%2B45%203374%208404 3374 8404
http://smk.dk/ smk.dk

<image005.jpg>

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org

Thank you very much for those swift and detailed answers.

I tackle the job and let you know as soon as the services works.

Br,
Sébastien

Fra: Patrick Schmitz [mailto:pschmitz@berkeley.edu]
Sendt: 25. juli 2012 02:10
Til: 'Aron Roberts'; 'Ray Lee'
Cc: talk@lists.collectionspace.org; Sébastien Brossard
Emne: RE: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType

As to the app layer support for structured dates, it should actually work okay. The tenant override will inject the new field(s) into the base-other-structureddate definition. It is a sub-record, so it is actually somewhat more flexible in some ways that other repeating groups. I think that the app layer logic will be okay if you just add fields.

You may have to change the way you declare it when it occurs in other records, but we'll cross that bridge we get to it.

As Ray says, get the services working, and we'll help from there.

Patrick

From: talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org]mailto:[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Aron Roberts
Sent: Tuesday, July 24, 2012 4:39 PM
To: Ray Lee
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org; Sébastien Brossard
Subject: Re: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType
Ray wrote:

Agreed completely, Ray.  These's a JIRA issue to begin documenting this:
http://issues.collectionspace.org/browse/CSPACE-5070

This should get done in either the Doc5 sprint (currently ongoing) or if not by then, by no later than the next one (Doc6); it's a huge priority.

Aron
On Tue, Jul 24, 2012 at 3:52 PM, Ray Lee <rhlee@berkeley.edumailto:rhlee@berkeley.edu> wrote:
Hi Sébastien,
I think what you're trying to do is going to end up being quite complex, so you haven't missed anything. In the services layer, I think you're right to create a new complex type (structuredDateGroupSMK) in your local schema. The structuredDateGroupSMK type would be identical to structuredDateGroup from the common schema, except for the addition of your new field (dateSMKDisplayText). You won't be able to change existing fields in the common schema to be structuredDateGroupSMK instead of structuredDateGroup. You'll have to create new fields in the local schema that have type structuredDateGroupSMK, and use these new fields as replacements for the ones in the common schema.

As a first step, I would create a new field of type structuredDateGroupSMK in your local schema, and use the REST API to read and write that field. Then you'll know that the services layer is configured properly. Then you can move on to the app layer. I'm not sure if you can make this work entirely through xml configuration. This may require modification to the app layer's java code, because there's some special handling for structured dates in there.

The lifesci tenant is using a new (as of 2.3) way of configuring the app layer that potentially makes things easier, but you don't have to use it. The way you've been doing it still works. The new app layer merge stuff really needs to get documented.

If you get the services layer working, let us know. I might be able to help more with the app layer.

Thanks,
Ray

On Jul 23, 2012, at 1:13 AM, Sébastien Brossard wrote:

Dear all,
I'm currently trying to add some customized fields in the frame of SMK's Local Schema Extension.

As a first try, I could successfully add a new xs:element in the domain-collectionobject,
(I added two files in SMK's tenant:

• services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd
• application/.../tenant/smk/ domain-collectionobject.xml

• modified my ui so that to show my new field. It worked fine, showed and saved field's value.)

But here it's a bit more complex : I would like to add some fields in the StructuredDate component.

More precisely, I want to add a new xs:element (dateSMKDisplayText) in <xs:complexType name="structuredDateGroup">

•     I tried by many many ways to add my new element in the existing structuredDateGroup via SMK's tenant, without any success.
  

•     Looking at the lifesci example, I tried to create a new complex type "structuredDateGroupSMK" (which means that I had to create a new <xs:element> who supports this new complex type ), but:
  

o  In lifesci-tenant.xml there's a merging function that I don't know nothing about (<include src="base-collectionobject.xml,naturalhistory-collectionobject.xml" merge="xmlmerge.properties"/>), which confused me.
o  structuredDateGroup is used in many places in the code, which means that I should replace it in numerous places in the code - which I think is not a brilliant idea.

It seems a bit too much complex, so I suppose I missed a simpler way to achieve this.

Thank you by advance for your kindly help and tips.

Best regards,
Sébastien

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image004.jpg>

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image005.jpg>

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Dear all,

Setting up of the service was easily achieved, and REST tests are successful with the following configuration :

·        In "services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd":

<xs:element name="contentDateGroupSMK" type="structuredDateGroupSMK"/>

<xs:complexType name="structuredDateGroupSMK">

xs:sequence

<xs:element name="dateSMKDisplayText" type="xs:string"/>

<xs:element name="dateSMKDateDay" type="xs:string"/>

        <xs:element name="dateSMKDateMonth" type="xs:string"/>

        <xs:element name="dateSMKDateYear" type="xs:string"/>

        <xs:element name="dateSMKEraSelector" type="xs:string"/>

        <xs:element name="dateSMKSecondDateDay" type="xs:string"/>

        <xs:element name="dateSMKSecondDateMonth" type="xs:string"/>

        <xs:element name="dateSMKSecondDateYear" type="xs:string"/>

        <xs:element name="dateSMKSecondEraSelector" type="xs:string"/>

        <xs:element name="dateSMKThirdDateDay" type="xs:string"/>

        <xs:element name="dateSMKThirdDateMonth" type="xs:string"/>

        <xs:element name="dateSMKThirdDateYear" type="xs:string"/>

        <xs:element name="dateSMKThirdEraSelector" type="xs:string"/>

        <xs:element name="dateSMKSegmentSelector" type="xs:string"/>

        <xs:element name="dateSMKTypeSelector" type="xs:string"/>

    </xs:sequence>

</xs:complexType>

(as you'll have noticed, I'm actually trying to add more than one field in structuredDate)

... but I'm unable to have the application layer working properly.
I've made many many many attempts, but I think the most significant are (n.b. as to simplify things, I reduced my new fields to one during those tries ):

·        Test1:
In "application/.../tenant/smk/ base-other-structureddate.xml":

<xs:element name="dateSMKDisplayText" type="xs:string"/>

            </section>

-->Resulting ERROR MESSAGE when loading "cataloging.html": "Error fetching ../../../tenant/smk/composite: error"

·        Test2

In "application/.../tenant/smk/ base-other-structureddate.xml":

<xs:element name="dateSMKDisplayText" type="xs:string"/>

            </section>

·        Test3: same as above + add all the fields from the core base-other-structureddate.xml

IN BOTH CASES (Test2 & Test3):

-->Resulting ERROR MESSAGE when saving a new cataloging record: "Cannot set IS_REMOVED on removed or properties that are not map elements"

·        Test4: I re-did Test1 & Test2 & Test3 + changed <services-tag> to contentDateGroupSMK in "application/.../default/ base-other-structureddate.xml"

-->ERROR ERROR ERROR

I also sniffed data sent to the application and retrieved the JASON (at least I think it is JASON) packet: I found here my SMK fields, but other time also the original fields - I must admit I didn't really understand how JASON packets are created.

I'm running out of ideas soon - hoping for a kind of clairvoyant revelation tonight?
In case it doesn't come, any suggestion would be a huge help!!

Thank you by advance.

Best regards,
Sébastien
Ps: I forgot to say in my previous message: I'm currently working with CS v2.3

Fra: Patrick Schmitz [mailto:pschmitz@berkeley.edu]mailto:[mailto:pschmitz@berkeley.edu]
Sendt: 25. juli 2012 02:10
Til: 'Aron Roberts'; 'Ray Lee'
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org; Sébastien Brossard
Emne: RE: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType

As to the app layer support for structured dates, it should actually work okay. The tenant override will inject the new field(s) into the base-other-structureddate definition. It is a sub-record, so it is actually somewhat more flexible in some ways that other repeating groups. I think that the app layer logic will be okay if you just add fields.

You may have to change the way you declare it when it occurs in other records, but we'll cross that bridge we get to it.

As Ray says, get the services working, and we'll help from there.

Patrick

From: talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org]mailto:[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Aron Roberts
Sent: Tuesday, July 24, 2012 4:39 PM
To: Ray Lee
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org; Sébastien Brossard
Subject: Re: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType
Ray wrote:

Agreed completely, Ray.  These's a JIRA issue to begin documenting this:
http://issues.collectionspace.org/browse/CSPACE-5070

This should get done in either the Doc5 sprint (currently ongoing) or if not by then, by no later than the next one (Doc6); it's a huge priority.

Aron
On Tue, Jul 24, 2012 at 3:52 PM, Ray Lee <rhlee@berkeley.edumailto:rhlee@berkeley.edu> wrote:
Hi Sébastien,
I think what you're trying to do is going to end up being quite complex, so you haven't missed anything. In the services layer, I think you're right to create a new complex type (structuredDateGroupSMK) in your local schema. The structuredDateGroupSMK type would be identical to structuredDateGroup from the common schema, except for the addition of your new field (dateSMKDisplayText). You won't be able to change existing fields in the common schema to be structuredDateGroupSMK instead of structuredDateGroup. You'll have to create new fields in the local schema that have type structuredDateGroupSMK, and use these new fields as replacements for the ones in the common schema.

As a first step, I would create a new field of type structuredDateGroupSMK in your local schema, and use the REST API to read and write that field. Then you'll know that the services layer is configured properly. Then you can move on to the app layer. I'm not sure if you can make this work entirely through xml configuration. This may require modification to the app layer's java code, because there's some special handling for structured dates in there.

The lifesci tenant is using a new (as of 2.3) way of configuring the app layer that potentially makes things easier, but you don't have to use it. The way you've been doing it still works. The new app layer merge stuff really needs to get documented.

If you get the services layer working, let us know. I might be able to help more with the app layer.

Thanks,
Ray

On Jul 23, 2012, at 1:13 AM, Sébastien Brossard wrote:

Dear all,
I'm currently trying to add some customized fields in the frame of SMK's Local Schema Extension.

As a first try, I could successfully add a new xs:element in the domain-collectionobject,
(I added two files in SMK's tenant:

• services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd
• application/.../tenant/smk/ domain-collectionobject.xml

• modified my ui so that to show my new field. It worked fine, showed and saved field's value.)

But here it's a bit more complex : I would like to add some fields in the StructuredDate component.

More precisely, I want to add a new xs:element (dateSMKDisplayText) in <xs:complexType name="structuredDateGroup">

•     I tried by many many ways to add my new element in the existing structuredDateGroup via SMK's tenant, without any success.
  

•     Looking at the lifesci example, I tried to create a new complex type "structuredDateGroupSMK" (which means that I had to create a new <xs:element> who supports this new complex type ), but:
  

o  In lifesci-tenant.xml there's a merging function that I don't know nothing about (<include src="base-collectionobject.xml,naturalhistory-collectionobject.xml" merge="xmlmerge.properties"/>), which confused me.
o  structuredDateGroup is used in many places in the code, which means that I should replace it in numerous places in the code - which I think is not a brilliant idea.

It seems a bit too much complex, so I suppose I missed a simpler way to achieve this.

Thank you by advance for your kindly help and tips.

Best regards,
Sébastien

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image004.jpg>

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image005.jpg>

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi all,

I re-send the mail below, Chris told me it hasn't reached him on the talk@list

Br,
Sébastien

Fra: Sébastien Brossard
Sendt: 30. juli 2012 16:43
Til: 'Patrick Schmitz'; 'Aron Roberts'; 'Ray Lee'
Cc: talk@lists.collectionspace.org
Emne: SV: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType

Dear all,

Setting up of the service was easily achieved, and REST tests are successful with the following configuration :

·        In "services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd":

<xs:element name="contentDateGroupSMK" type="structuredDateGroupSMK"/>

<xs:complexType name="structuredDateGroupSMK">

xs:sequence

<xs:element name="dateSMKDisplayText" type="xs:string"/>

<xs:element name="dateSMKDateDay" type="xs:string"/>

        <xs:element name="dateSMKDateMonth" type="xs:string"/>

        <xs:element name="dateSMKDateYear" type="xs:string"/>

        <xs:element name="dateSMKEraSelector" type="xs:string"/>

        <xs:element name="dateSMKSecondDateDay" type="xs:string"/>

        <xs:element name="dateSMKSecondDateMonth" type="xs:string"/>

        <xs:element name="dateSMKSecondDateYear" type="xs:string"/>

        <xs:element name="dateSMKSecondEraSelector" type="xs:string"/>

        <xs:element name="dateSMKThirdDateDay" type="xs:string"/>

        <xs:element name="dateSMKThirdDateMonth" type="xs:string"/>

        <xs:element name="dateSMKThirdDateYear" type="xs:string"/>

        <xs:element name="dateSMKThirdEraSelector" type="xs:string"/>

        <xs:element name="dateSMKSegmentSelector" type="xs:string"/>

        <xs:element name="dateSMKTypeSelector" type="xs:string"/>

    </xs:sequence>

</xs:complexType>

(as you'll have noticed, I'm actually trying to add more than one field in structuredDate)

... but I'm unable to have the application layer working properly.
I've made many many many attempts, but I think the most significant are (n.b. as to simplify things, I reduced my new fields to one during those tries ):

·        Test1:
In "application/.../tenant/smk/ base-other-structureddate.xml":

<xs:element name="dateSMKDisplayText" type="xs:string"/>

            </section>

-->Resulting ERROR MESSAGE when loading "cataloging.html": "Error fetching ../../../tenant/smk/composite: error"

·        Test2

In "application/.../tenant/smk/ base-other-structureddate.xml":

<xs:element name="dateSMKDisplayText" type="xs:string"/>

            </section>

·        Test3: same as above + add all the fields from the core base-other-structureddate.xml

IN BOTH CASES (Test2 & Test3):

-->Resulting ERROR MESSAGE when saving a new cataloging record: "Cannot set IS_REMOVED on removed or properties that are not map elements"

·        Test4: I re-did Test1 & Test2 & Test3 + changed <services-tag> to contentDateGroupSMK in "application/.../default/ base-other-structureddate.xml"

-->ERROR ERROR ERROR

I also sniffed data sent to the application and retrieved the JASON (at least I think it is JASON) packet: I found here my SMK fields, but other time also the original fields - I must admit I didn't really understand how JASON packets are created.

I'm running out of ideas soon - hoping for a kind of clairvoyant revelation tonight?
In case it doesn't come, any suggestion would be a huge help!!

Thank you by advance.

Best regards,
Sébastien
Ps: I forgot to say in my previous message: I'm currently working with CS v2.3

Fra: Patrick Schmitz [mailto:pschmitz@berkeley.edu]mailto:[mailto:pschmitz@berkeley.edu]
Sendt: 25. juli 2012 02:10
Til: 'Aron Roberts'; 'Ray Lee'
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org; Sébastien Brossard
Emne: RE: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType

As to the app layer support for structured dates, it should actually work okay. The tenant override will inject the new field(s) into the base-other-structureddate definition. It is a sub-record, so it is actually somewhat more flexible in some ways that other repeating groups. I think that the app layer logic will be okay if you just add fields.

You may have to change the way you declare it when it occurs in other records, but we'll cross that bridge we get to it.

As Ray says, get the services working, and we'll help from there.

Patrick

From: talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org]mailto:[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Aron Roberts
Sent: Tuesday, July 24, 2012 4:39 PM
To: Ray Lee
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org; Sébastien Brossard
Subject: Re: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType
Ray wrote:

Agreed completely, Ray.  These's a JIRA issue to begin documenting this:
http://issues.collectionspace.org/browse/CSPACE-5070

This should get done in either the Doc5 sprint (currently ongoing) or if not by then, by no later than the next one (Doc6); it's a huge priority.

Aron
On Tue, Jul 24, 2012 at 3:52 PM, Ray Lee <rhlee@berkeley.edumailto:rhlee@berkeley.edu> wrote:
Hi Sébastien,
I think what you're trying to do is going to end up being quite complex, so you haven't missed anything. In the services layer, I think you're right to create a new complex type (structuredDateGroupSMK) in your local schema. The structuredDateGroupSMK type would be identical to structuredDateGroup from the common schema, except for the addition of your new field (dateSMKDisplayText). You won't be able to change existing fields in the common schema to be structuredDateGroupSMK instead of structuredDateGroup. You'll have to create new fields in the local schema that have type structuredDateGroupSMK, and use these new fields as replacements for the ones in the common schema.

As a first step, I would create a new field of type structuredDateGroupSMK in your local schema, and use the REST API to read and write that field. Then you'll know that the services layer is configured properly. Then you can move on to the app layer. I'm not sure if you can make this work entirely through xml configuration. This may require modification to the app layer's java code, because there's some special handling for structured dates in there.

The lifesci tenant is using a new (as of 2.3) way of configuring the app layer that potentially makes things easier, but you don't have to use it. The way you've been doing it still works. The new app layer merge stuff really needs to get documented.

If you get the services layer working, let us know. I might be able to help more with the app layer.

Thanks,
Ray

On Jul 23, 2012, at 1:13 AM, Sébastien Brossard wrote:

Dear all,
I'm currently trying to add some customized fields in the frame of SMK's Local Schema Extension.

As a first try, I could successfully add a new xs:element in the domain-collectionobject,
(I added two files in SMK's tenant:

• services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd
• application/.../tenant/smk/ domain-collectionobject.xml

• modified my ui so that to show my new field. It worked fine, showed and saved field's value.)

But here it's a bit more complex : I would like to add some fields in the StructuredDate component.

More precisely, I want to add a new xs:element (dateSMKDisplayText) in <xs:complexType name="structuredDateGroup">

•     I tried by many many ways to add my new element in the existing structuredDateGroup via SMK's tenant, without any success.
  

•     Looking at the lifesci example, I tried to create a new complex type "structuredDateGroupSMK" (which means that I had to create a new <xs:element> who supports this new complex type ), but:
  

o  In lifesci-tenant.xml there's a merging function that I don't know nothing about (<include src="base-collectionobject.xml,naturalhistory-collectionobject.xml" merge="xmlmerge.properties"/>), which confused me.
o  structuredDateGroup is used in many places in the code, which means that I should replace it in numerous places in the code - which I think is not a brilliant idea.

It seems a bit too much complex, so I suppose I missed a simpler way to achieve this.

Thank you by advance for your kindly help and tips.

Best regards,
Sébastien

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image004.jpg>

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image005.jpg>

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi all,

You can forget my previous messages, they're out of date, sooo this morning.

Chris is back from holidays and he's been a huge help.
But even if we're getting closer, SMK's fields still can't be saved.

The new conf is:

·        In "services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd":

<xs:element name="contentDateGroupSMK" type="structuredDateGroupSMK"/>

<xs:complexType name="structuredDateGroupSMK">

xs:sequence

<xs:element name="dateSMKDisplayText" type="xs:string"/>

    </xs:sequence>

</xs:complexType>

·        In "application/.../tenant/smk/ base-other-structureddateSMK.xml":

            <section>

                            <field id="dateSMKDisplayText">

                 <selector>dateSMKDisplayText</selector>

                          <preselector></preselector>

                </field>

            </section>

        </record>

·        In "application/.../tenant/smk-tenant.xml":

We added this line:

·        In "application/.../tenant/smk/ base-collectionobject.xml":
We copied the defaut base-collectionobject.xml  and we added this field:

<field id="contentDateSMK" ui-search="range" ui-type="groupfield/structureddateSMK" primarykey="contentDateSMK.dateSMKDisplayText" ui-func="cspace.structuredDate">

    <services-tag>contentDateSMKGroup</services-tag>
    <selector>object-description-content-date-smk</selector>

·        In "ui/.../tenants/smk/html/pages/cataloging.html"

We copied default file and added this field to default file's content:

·        In "ui/.../tenants/smk/js/StructuredDate.js" AND in "ui/.../tenants/smk/html/component/StructuredDate.html"

We copied default file and added our dateSMKDisplayText to default file's content

è So the result is now, that in a new record page, we can see our dateSMKDisplayText field in content-structureddate, we can write a value, and when we re-open the content-structureddate, the value is still there.

But it's not saved when the button is pressed.

Present questions are now:

·        We wondered about creating a new StructuredDateSMK.js and StructuredDateSMK.html, but it was impossible to insert a new <script type="text/javascript" src="../js/StructuredDateSMK.js"></script> in cataloging.html ??

Even after adding this line in record.html and template.html, StructuredDateSMK.js doesn't show up in cataloging.html. To be exact: we can see in the source code of the page, but not in firebugs (after cleaning the cache, of course).

·        How does ui-func work in "application/.../tenant/smk/ base-collectionobject.xml" ?
We tried to change its value to "cspace.structuredDateSMK"  and doing subsequent changes in "ui/.../StructuredDate.js" and ""ui/.../Demands.js", but without success: cataloging.html is not loading.

Thank you again for your kindly help, and have a nice day!

Best regards,

Sébastien

Fra: Sébastien Brossard
Sendt: 1. august 2012 08:58
Til: 'talk@lists.collectionspace.org'
Emne: VS: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType

Hi all,

I re-send the mail below, Chris told me it hasn't reached him on the talk@list

Br,
Sébastien

Fra: Sébastien Brossard
Sendt: 30. juli 2012 16:43
Til: 'Patrick Schmitz'; 'Aron Roberts'; 'Ray Lee'
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org
Emne: SV: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType

Dear all,

Setting up of the service was easily achieved, and REST tests are successful with the following configuration :

·        In "services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd":

<xs:element name="contentDateGroupSMK" type="structuredDateGroupSMK"/>

<xs:complexType name="structuredDateGroupSMK">

xs:sequence

<xs:element name="dateSMKDisplayText" type="xs:string"/>

<xs:element name="dateSMKDateDay" type="xs:string"/>

        <xs:element name="dateSMKDateMonth" type="xs:string"/>

        <xs:element name="dateSMKDateYear" type="xs:string"/>

        <xs:element name="dateSMKEraSelector" type="xs:string"/>

        <xs:element name="dateSMKSecondDateDay" type="xs:string"/>

        <xs:element name="dateSMKSecondDateMonth" type="xs:string"/>

        <xs:element name="dateSMKSecondDateYear" type="xs:string"/>

        <xs:element name="dateSMKSecondEraSelector" type="xs:string"/>

        <xs:element name="dateSMKThirdDateDay" type="xs:string"/>

        <xs:element name="dateSMKThirdDateMonth" type="xs:string"/>

        <xs:element name="dateSMKThirdDateYear" type="xs:string"/>

        <xs:element name="dateSMKThirdEraSelector" type="xs:string"/>

        <xs:element name="dateSMKSegmentSelector" type="xs:string"/>

        <xs:element name="dateSMKTypeSelector" type="xs:string"/>

    </xs:sequence>

</xs:complexType>

(as you'll have noticed, I'm actually trying to add more than one field in structuredDate)

... but I'm unable to have the application layer working properly.
I've made many many many attempts, but I think the most significant are (n.b. as to simplify things, I reduced my new fields to one during those tries ):

·        Test1:
In "application/.../tenant/smk/ base-other-structureddate.xml":

<xs:element name="dateSMKDisplayText" type="xs:string"/>

            </section>

-->Resulting ERROR MESSAGE when loading "cataloging.html": "Error fetching ../../../tenant/smk/composite: error"

·        Test2

In "application/.../tenant/smk/ base-other-structureddate.xml":

<xs:element name="dateSMKDisplayText" type="xs:string"/>

            </section>

·        Test3: same as above + add all the fields from the core base-other-structureddate.xml

IN BOTH CASES (Test2 & Test3):

-->Resulting ERROR MESSAGE when saving a new cataloging record: "Cannot set IS_REMOVED on removed or properties that are not map elements"

·        Test4: I re-did Test1 & Test2 & Test3 + changed <services-tag> to contentDateGroupSMK in "application/.../default/ base-other-structureddate.xml"

-->ERROR ERROR ERROR

I also sniffed data sent to the application and retrieved the JASON (at least I think it is JASON) packet: I found here my SMK fields, but other time also the original fields - I must admit I didn't really understand how JASON packets are created.

I'm running out of ideas soon - hoping for a kind of clairvoyant revelation tonight?
In case it doesn't come, any suggestion would be a huge help!!

Thank you by advance.

Best regards,
Sébastien
Ps: I forgot to say in my previous message: I'm currently working with CS v2.3

Fra: Patrick Schmitz [mailto:pschmitz@berkeley.edu]mailto:[mailto:pschmitz@berkeley.edu]
Sendt: 25. juli 2012 02:10
Til: 'Aron Roberts'; 'Ray Lee'
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org; Sébastien Brossard
Emne: RE: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType

As to the app layer support for structured dates, it should actually work okay. The tenant override will inject the new field(s) into the base-other-structureddate definition. It is a sub-record, so it is actually somewhat more flexible in some ways that other repeating groups. I think that the app layer logic will be okay if you just add fields.

You may have to change the way you declare it when it occurs in other records, but we'll cross that bridge we get to it.

As Ray says, get the services working, and we'll help from there.

Patrick

From: talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org]mailto:[mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Aron Roberts
Sent: Tuesday, July 24, 2012 4:39 PM
To: Ray Lee
Cc: talk@lists.collectionspace.orgmailto:talk@lists.collectionspace.org; Sébastien Brossard
Subject: Re: [Talk] Local Schema Extension: adding a new xs:element inxs:complexType
Ray wrote:

Agreed completely, Ray.  These's a JIRA issue to begin documenting this:
http://issues.collectionspace.org/browse/CSPACE-5070

This should get done in either the Doc5 sprint (currently ongoing) or if not by then, by no later than the next one (Doc6); it's a huge priority.

Aron
On Tue, Jul 24, 2012 at 3:52 PM, Ray Lee <rhlee@berkeley.edumailto:rhlee@berkeley.edu> wrote:
Hi Sébastien,
I think what you're trying to do is going to end up being quite complex, so you haven't missed anything. In the services layer, I think you're right to create a new complex type (structuredDateGroupSMK) in your local schema. The structuredDateGroupSMK type would be identical to structuredDateGroup from the common schema, except for the addition of your new field (dateSMKDisplayText). You won't be able to change existing fields in the common schema to be structuredDateGroupSMK instead of structuredDateGroup. You'll have to create new fields in the local schema that have type structuredDateGroupSMK, and use these new fields as replacements for the ones in the common schema.

As a first step, I would create a new field of type structuredDateGroupSMK in your local schema, and use the REST API to read and write that field. Then you'll know that the services layer is configured properly. Then you can move on to the app layer. I'm not sure if you can make this work entirely through xml configuration. This may require modification to the app layer's java code, because there's some special handling for structured dates in there.

The lifesci tenant is using a new (as of 2.3) way of configuring the app layer that potentially makes things easier, but you don't have to use it. The way you've been doing it still works. The new app layer merge stuff really needs to get documented.

If you get the services layer working, let us know. I might be able to help more with the app layer.

Thanks,
Ray

On Jul 23, 2012, at 1:13 AM, Sébastien Brossard wrote:

Dear all,
I'm currently trying to add some customized fields in the frame of SMK's Local Schema Extension.

As a first try, I could successfully add a new xs:element in the domain-collectionobject,
(I added two files in SMK's tenant:

• services/.../ nuxeo-platform-collectionobject-smk/.../shemas/ collectionobjects_smk.xsd
• application/.../tenant/smk/ domain-collectionobject.xml

• modified my ui so that to show my new field. It worked fine, showed and saved field's value.)

But here it's a bit more complex : I would like to add some fields in the StructuredDate component.

More precisely, I want to add a new xs:element (dateSMKDisplayText) in <xs:complexType name="structuredDateGroup">

•     I tried by many many ways to add my new element in the existing structuredDateGroup via SMK's tenant, without any success.
  

•     Looking at the lifesci example, I tried to create a new complex type "structuredDateGroupSMK" (which means that I had to create a new <xs:element> who supports this new complex type ), but:
  

o  In lifesci-tenant.xml there's a merging function that I don't know nothing about (<include src="base-collectionobject.xml,naturalhistory-collectionobject.xml" merge="xmlmerge.properties"/>), which confused me.
o  structuredDateGroup is used in many places in the code, which means that I should replace it in numerous places in the code - which I think is not a brilliant idea.

It seems a bit too much complex, so I suppose I missed a simpler way to achieve this.

Thank you by advance for your kindly help and tips.

Best regards,
Sébastien

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image004.jpg>

Sébastien Brossard
IT-Udvikler
sebastien.brossard@smk.dkmailto:3sebastien.brossard@smk.dkT
Tmailto:3sebastien.brossard@smk.dkT +45 3374 8483tel:%2B45%203374%208483

Statens Museum for Kunst
Sølvgade 48-50
DK-1307 København K

T +45 3374 8494tel:%2B45%203374%208494
F +45 3374 8404tel:%2B45%203374%208404
smk.dkhttp://smk.dk/

<image005.jpg>

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Sébastien,

I went through something similar a few weeks ago where I wanted to modify
the Structured Date widget for a custom tenant.

Here's the thread from the discussion from the Talk list
http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2012-June/000834.html

What I ended up coming up with was to modify the StructuredDate.js with my
slight modifications appended. (Since creating a new StructuredDateMMI.js
file would have been a bit more work.)

It's not the best code since it's repetitive and needs to be refactored.
Feel free to view the code:
https://github.com/jessemartinez/ui/blob/MMI-13/src/main/webapp/tenants/mmi/js/StructuredDate.js

It's also necessary to modify the application layer's configuration for
that specific structured date field. For instance I made a modification for
the structured date field in the Person authority record that references
the component I created in StructuredDate.js
https://github.com/jessemartinez/application/blob/MMI-12/tomcat-main/src/main/resources/tenants/mmi/local-authority-person.xml#L50

Hope this helps,

• Jesse

On Wed, Aug 1, 2012 at 10:38 AM, Sébastien Brossard <
Sebastien.Brossard@smk.dk> wrote:

Hi Sébastien,
You probably weren't able to see the script you added to cataloging.html, because that file is cached in the app cache. Just clearing the "normal" cache in the browser isn't enough. You have to take an extra step to clear the app cache, in both Chrome and Firefox. Here are instructions for doing that:

https://developer.mozilla.org/en/Offline_resources_in_Firefox/#Storage_location_and_clearing_the_offline_cache

And here are instructions for configuring which cspace files go into the app cache, and forcing the browser to reload files in the app cache, if you make a modification:

http://wiki.collectionspace.org/display/UNRELEASED/How+to+Update+UI+Files+that+are+in+the+Offline+Application+Cache

Thanks,
Ray

On Aug 1, 2012, at 8:04 AM, Jesse Martinez wrote: