Issues with dynamically generated j_idt id's when testing a jsf majora 2.011 application

Hi,

Using HP PC 11.52 I have been assigned to setup a performance test for a web application being developed with JSF Majora 2.011.
Ideally I would script this with AJAX TruClient, and for some use cases this works fine. However the majority of the use cases include a document download to the client machine, modifying the doc and saving it an sending it back to the server. This is where TruClient fails. As soon as the download occurs, TruClient will not record that. So I decided to go for http/HTML scripting. Http/HTML will record the GETs and POSTs involved in the download/upload. OK, what I am missing now is that I cannot change the doc. but that's not such a big deal, at least the GET's and POST's involved in the document transaction are captured and replayed, so the load will be generated on the server (and the size of the doc does not change that much anyway)
Making it work using http/HTML scripting is tedious but I did actually got one sample use case to work, parameterized and all (totally 2200 lines of generated script). There is however one major disadvantage besides the scripting time required: each time a new build of the application is generated, the jsf framework will dynamically create new id's (which look like j_idtXXXX, where X is a digit) for menu's, button, forms etc. These were all of course in the stored in the original recording and become useless once a new build is generated.

Here's a piece of script which illustrates it:

web_custom_request("viewSelector.xhtml_21",
    "URL=http://{serverURL}.xhtml",
    "Method=POST",
    "TargetFrame=",
    "Resource=0",
    "RecContentType=text/xml",
    "Referer=http://{serverURL}.xhtml",
    "Snapshot=t596.inf",
    "Mode=HTML",
    "EncType=application/x-www-form-urlencoded;charset=UTF-8",
        "Body=j_idt5793%3Aj_idt11=j_idt5793%3Aj_idt11&javax.faces.ViewState={javax.faces.ViewState_URL}&javax.faces.source=j_idt5940&javax.faces.partial.execute=j_idt5940%20%40component&javax.faces.partial.render=%40component&focusOnFieldName=tijd&org.richfaces.ajax.component=j_idt5940&j_idt5940=j_idt5940&rfExt=null&AJAX%3AEVENTS_COUNT=1&javax.faces.partial.ajax=true",
    LAST);

So now I am questioning what is an efficient approach here:

1. Of course I would be in favor of NOT changing the j_idt id's at all, but developers tell me that they cannot influence it, its just the way how jsf works.
   
   
2. Parameterize the j_idt id's all together so the scripts become fully independent of it. While this is possible, it is a lot of work and then you just hope that nothing else changes as well. There is a high risk.
   
   
3. Create a working script for ach use case at least once and then use these as templates for every next build of the application. Each new build now will require me to rerecord the whole usecase, but at least I can do a search and replace using the template.

Surely there must be people out there having experience with performance testing jsf applications who have encountered this problem as well...
Please share your experience on best practices in such a case.

Thanks,

Peet