Copying values

In one of my Postprocessor extensions, I am trying to copy the value from sys_title field to another field called: url. I have the following piece of code:

Object titleObject = ipsrequestcontext.getParameterObject(“sys_title”);
ipsrequestcontext.setParameter(“url”, titleObject);

It is not working, as I not able to see the value appear in “url” field. However, if I print out

I do see the string in sys_title field…which means the set was done. However, the value doesnot gets displayed in the url field.

I know I am missing something. Can someone please point out what is missing in the above piece of code?


I also tried to copy using the following code in my extension:

PSCopyParameter psc=new PSCopyParameter();
psc.preProcessRequest(new Object[]{“sys_title”, “url”}, ipsrequestcontext);

But still no sucess. I dont see the values copied in the url field.

It’s not clear to me what you’re really trying to do here. If you are trying to copy a field on INPUT (that is, the user has inserted or edited the item, and you want the URL field to have the same contents as the sys_title field).

In this case, use the PSCopyParameter extension as a “Pre-Processor” extension, not a post-processor extension.

As you have seen from your “experiments”, adding parameters in a Post Processor extension has no effect on the contents of the field.

If this is not what you are trying to do, please describe your usage scenario in some more detail.


Ignore this post!!

Yes…you are right once I changed the type to Pre processor it worked out fine. When does the Post processor extension gets executed? Is it after we press the Update/ Insert button on Content Item window?

Also is there any rule of thumb when we should pre processor and when post processor extensions?


Yes, post-processors are run when you submit the Content Item to the Repository. (Pre-processors are run when the Content Item is retrieved from the Repository.) For a graphical representation of this processing, in the Rhythmyx Technical Reference (Version 6.6 link), see the topic “Content Processing”.


The situation is actually a bit more complicated than Bob describes…

Pre-processors run whenever the user makes a request of the server. The pre-processor can change the parameters and/or add new ones

Post-processors run after the server generates its internal XML document, before transforming them into the resulting HTML form. Post-processors are usually used to modify the XML document to add new information.

This means that both types of extensions run on EVERY request, but at different points in the request/response cycle.

I believe in that case most of our extensions will fit in the preprocessor category. Can you pl. give some examples of scenarios which might require a Post Processor extension.

I am having a hard time to visualize what could ever qualify for Post processor as you described as: "Post-processors run after the server generates its internal XML document, before transforming them into the resulting HTML form. Post-processors are usually used to modify the XML document to add new information. "


Perhaps a real example might help.

We have a customer who wanted different workflow choices in each community (for the same content type). We built a post-processor extension that looks up the community (in a table) and sets the workflow choices according to the contents of the table.

These things are much less common than “pre-processor” extensions.

I recently dealt with a customer who had questions about the order of Pre- and Post-processing as well as Item Validation, and I was informed of this thread. I would like to post my findings, as some of the data provided here is no longer accurate.

I just spoke with one of our Developers and he has given me the exact order of the actions. The order is the same whether you are saving a new item or saving an existing item (the only difference in whether the data is overwritten or created). Upon creating a new item, nothing occurs until you try to save it.


  1. Item-level Input Transforms
  2. Field-level Input Transforms
  3. Field-level Validation
  4. Item-level Pre-Processing
  5. Data is saved at this point
  6. Post-Processing of Extensions


  1. Pre-Processing of Extensions
  2. Data is loaded
  3. Post-Processing of Extensions
  4. Item-level Output Transforms
  5. Field-level Output Transforms
    Note that there is no validation run upon Load.

Workflow Transitions:

  1. Item-level Validation
  2. Pre-Processing of Extensions
  3. The Transition occurs at this point
  4. Post-processing of Extensions


  1. Pre-Processing of Extensions
  2. The Check-In/Out occurs at this point
  3. Post-processing of Extensions

Please note that our documentation, as of this writing, has a minor error stating that Item Validation is run during Check-In and Check-Out actions. This is inaccurate as of this writing. I have brought this to the attention of our Documentation Team.