cancel
Showing results for 
Search instead for 
Did you mean: 

How to override cm:contains association?

nenad982
Champ on-the-rise
Champ on-the-rise
Hi all,

is it possible and what is the nicest way to override 'duplicate' option of cm:contains association:


     <type name="cm:folder">
         <title>Folder</title>
         <parent>cm:cmobject</parent>
         <archive>true</archive>
         <associations>
            <child-association name="cm:contains">
               <source>
                  <mandatory>false</mandatory>
                  <many>true</many>
               </source>
               <target>
                  <class>sys:base</class>
                  <mandatory>false</mandatory>
                  <many>true</many>
               </target>
               <duplicate>false</duplicate>
               <propagateTimestamps>true</propagateTimestamps>
            </child-association>
         </associations>
      </type>


Thanks…
5 REPLIES 5

afaust
Legendary Innovator
Legendary Innovator
Hello,

AFAIK you can't really and you definitely SHOULD NOT. Almost all of the out-of-the-box functionality relies on cm:contains and how it behaves and if you were to change it, you would be bound to break your system in some way or another. It would be better to create your own child association and use that in custom functionality instead of cm:contains.

Regards
Axel

nenad982
Champ on-the-rise
Champ on-the-rise
Hi Axel,

when I did this I can not see my custom typo on Share UI any more. I can find it in node browser but on UI it does not show up.

I see just following aspects applied on the document on UI:

xzy:aProjektInfo
cm:auditable
xzy:aProjektMetadata
sys:referenceable
xzy:aDokumentersteller
sys:localized

I think that some aspects are missing and because of this I can not see document on UI. Following is my custom association:


<!– Base xzy folder type –>
      <type name="xyz:folder">
         <title>XYZ Ordner</title>
         <parent>cm:folder</parent>
         <archive>true</archive>
         <associations>
               <child-association name="xyz:contains">
                  <source>
                     <mandatory>false</mandatory>
                     <many>true</many>
                  </source>
                  <target>
                     <class>cm:content</class>
                     <mandatory>false</mandatory>
                     <many>true</many>
                  </target>
                  <duplicate>true</duplicate>
                  <propagateTimestamps>true</propagateTimestamps>
               </child-association>
            </associations>
      </type>


Before this I used cm:contains action on cm:folder and my application worked correctly. Now when I replaced this with xyz:contains and xyz:folder type, I don't see exceptions in the logs but I have issue that document is not visible on UI?

Do you know where the problem is?

Thanks

nenad982
Champ on-the-rise
Champ on-the-rise
I noticed that

cm:thumbnailModification
rn:renditioned

aspects missing. It seams that when cm:contains association is created using Java API it adds these aspects but my custm xyz:contains does not add these aspects and I can not see document in UI.

Do you have idea how to fix this?

Thanks

afaust
Legendary Innovator
Legendary Innovator
Hello,

there is no problem with any of the (missing) aspects. The Share UI does not work with custom child associations out-of-the-box and uses mainly cm:contains. Even if adapted to use other child associations, it will have issues with duplicate = true as some of its features use name-based lookup (e.g. highlighting during Navigation / event-based refreshes). You would need to use a customized UI for displaying any (custom) association with duplicate set to true.

Maybe you can elaborate why you feel you need to have duplicates. Its not a requirement that comes up often. Maybe there is a different solution than using duplicate names that you haven't considered yet…

Regards
Axel

nenad982
Champ on-the-rise
Champ on-the-rise
Thank you for your response. User just wanted to have this functionality because new documents will arrive in repo, after some time, which are not the version of the previous document with the same name. So because document is not new version we thought that this is logical way to go.
I see that this requires some additional work which we didn't plan so we probably will go with some kind of index appended on document name.

Thanks for your help.