copy a field to another field in post-processing

Rhythmyx Technical Discussion
1

Hi,

Is there a way to copy content from one field to another using post-processing? This is possible in pre-processing using sys_copyparameters.

Thanks

Georgina

2

Georgina,

It’s not clear what you mean by “post processing”. Do you want to do this at Assembly time, or something else?

Dave

3

Hi Dave,

Have you got a flow diagram of what happens when a content item is created? There is one in the documentation, but it clumps pre and post processing and in/output transforms together and does not show the interaction with the db.

It would be really useful to know where exactly each stage is executed, including where it actually inserts/updates into the DB.

Re my original question…

I want to be able to copy the parameter across after the user has clicked insert/update but before inserting the content into the DB.

Thanks

Georgina

4

In general, the order (somewhat simplified) is:

  1. User “submits” the content editor (causing a “POST” to the server)
  2. Pre-exits on the Content Editor run
  3. Input Translations on the Content Editor run
  4. Item is saved (Insert or update) and then “re-queried” from the database.
  5. Output Translations run
  6. Post-exits run
  7. Content is displayed in the editor form.

(Note: this assumes you start with the content editor open. There’s a slightly different sequence for creating a new (empty) content item, check out / workflow, etc.)

For your purposes, either a pre-exit (the “copy parameters” exit for example) or an input translation will work.

Dave

5

Hi Dave,

Ok thanks. That is useful to know.

If that is the case I don’t think what I had in mind would work.

Can you tell me the order for when an item is created? This would help with another problem we are having.

Thanks

Georgina

6

Hi Dave,

Thanks for the sequence of events. By “re-queried” I assume you mean a SELECT statement is issued to retrieve the values of fields from the database? This is interesting, because we have raised an issue with UK tech support because a trigger we have set up in our database works for everything except navons, which seem to be cached somehow on the application server, causing validation problems (the trigger is intended to ensure a unique system title.)

Andrew.

7

Andrew,

Yes, you’re correct that we perform a select.

Navons are handled very differently, although they are ordinary content items, and editing one should cause a database update.

Is that not what you are seeing?

Dave

8

For a create, the only difference is that an “empty” item is created. This empty item is populated with the “default” values defined for each field.

When the user presses the “insert” button, the sequence starts at step 1.

Dave

9

The database is updated, and the trigger is run to alter the value of the system title (it appends the content ID, in brackets, to ensure uniqueness.) But, in the case of navons, the application server continues to think (for want of a better word) that the system title is what it sent to the database, without the modification done by the trigger. You cannot then create another content item in the same folder with the same basic system title as the navon, e.g. “Foobar”, because it thinks it wouldn’t be unique - even though the system title of the navon as stored in the database is something like “Foobar (999)”, and the system title of the new item would be set to something like “Foobar (1000)” if it allowed the process to be completed. That is until you restart the Rhythmyx 6.5.2 server and all is well.

Andrew.

10

Thanks Dave. Useful to know.

11

Andrew,

You can achieve the same thing by adding a Navon title template in Navigation.properties.

navon.title.template={0}-({1})

will give you the same effect as your trigger, and it won’t require a restart. This may be documented somewhere, but I couldn’t find it easily.

The navon title template uses the same pattern as the Java MessageFormat class. The 0th element is the folder name, and the 1st element is the content id. You can supply any legal pattern.

This feature was intended for the purpose you describe: maintaining unique names for the Navon.

Also, you should note that database triggers are unsupported. For the most part, they work, but we don’t make any guarantees as to when they will work, or that they won’t break in the next release. We’d much rather you didn’t do this.

12

Thanks, I’ll give that a try.

13

Hello Dave,

Thank you, editing the Navigation.properties file as you suggested has done the trick. I have disabled the database trigger for navons, but kept it for ordinary content types so that those are guaranteed to have unique system titles as well. Still, it is strange that navons are somehow cached on the application server when all other content types re-query the database as part of the process of creating a content item. Hopefully it won’t trip us up again in the future now we know about it.

Thanks again,

Andrew.

14

Sorry, we still have a problem with this. I just realised that assigning a template to…

navon.title.template

…sets the display title. Is there another, similar instruction that would set the system title instead? We’ve already tried…

navon.sys_title.template

…and…

navon.systitle.template

…with no success. We have a Pre-Processing transform set up to copy the display title to the system title, hence the following…

navon.title.template={0} ({1})

…works in that it prevents validation messages caused by duplicate system titles in the same folder. But it means our navons are all going to have the content ID in brackets appended to their display titles as well, which shows up in the published web pages. And we have our system configured so that only administrators can edit navons, so ordinary users creating subfolders will not be able to manually edit the display titles to fix it.

Any other ideas?

Thanks,

Andrew.

15

Looking at the code, it’s clear that setting navon.title.template applies the template to BOTH the sys_title and displaytitle fields, so I don’t understand how they could be different.

How did you create this Navon ? The code I’m looking at runs when a new Navon is created because of a folder operation. Are you creating the Navon some other way ?

Also, if you don’t want the content id, don’t include the {1} in your template. What I gave you was just one example.

Dave

16

The navons were created automatically along with new subfolders.

If setting navon.title.template applies the template to BOTH the sys_title and displaytitle fields, then I guess we need to set up and output transform or post-processing transform to strip off the content ID in brackets from the displaytitle. We want the content ID in brackets in the sys_title to ensure all subsequent content items added to the same folder can be created with display titles that are the same as the navon that was automatically created along with the folder.

Andrew.

17

Andrew,

In this case you want in “input transform” not an “output transform”.

Dave

18

Thanks for the tip. We have indeed settled on an Input Field Transform on the sys_title field of the rffNavon content type, to append the word “navon” in brackets to the sys_title. We have removed the navon.title.template={0} ({1}) instruction from the Navigation.properties file, because we couldn’t prevent it being applied to both the sys_title and the displaytitle. In case anyone comes across a use for this in the future, it should be noted that the number appended is the content ID of the folder, not the navon itself. I guess the navon doesn’t have a content ID until it is added to the database. However, we are still a bit hazy over the order in which these things are done.

Thanks,

Andrew.

19

Andrew,

You’re correct that the Navon doesn’t have a content id until it is created, and so the content id is that of the new Folder, not the new Navon.

The Navon is created as a result of the creation of the folder relationship (where the new folder is added to the existing folder). At this point, the new Folder item exists (and it has a name) but it has not yet been added to the parent folder.

The new Navon is created (in memory), the name and display title are computed, and then the content editor is invoked to insert the new Navon. This is the point when your field input transforms run.

After the new Navon is saved, it will be added to the new Folder, as well as the Submenu slot on the parent Navon.

Only after these operations complete will the new Folder be added to the Parent folder.

This is probably more detail than you really want to know. Let me know if it helps, or if you have other specific questions.

Dave

20

Thanks Dave, that’s useful to know.

Andrew.