Hi Simon, setting the id for every naming container worked perfect and solved my problem!
Thank you very much! Felix Becker -----Ursprüngliche Nachricht----- Von: Simon Kitching [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 9. September 2008 15:26 An: MyFaces Discussion Betreff: Re: Generation strategy of the j_id prefixes? Hi Felix, [EMAIL PROTECTED] schrieb: > Hi, > > i'm currently writing JMeter tests for a web frontend generated with > myfaces. I tried to identify the input fields, buttons and drop downs > via their html id attribute. For example the id of one of my input > fields was: j_id36:inputContentText. After redeploying the application > the id changed to j_id42 - and my JMeter script broke. > > In the same document the prefix of the id changes, too. So the id of an > input field at the beginning of the document begins with j_id36 and at > the end of the document the id of an button begins with j_id48:. > > How are this id's generated, is it possible to turn them off and is > there any spec which defines / explains the generation of this ids? > When a component has no id assigned explicitly to it by the programmer, then the JSF framework assigns it an automatically-generated id, which may change. This is standard JSF behaviour, and not myfaces-specific. A few components are "naming containers" which add their own id as a prefix to the ids of their child components, like the absolute filename of a file contains the name of the parent directories. Naming container components include h:form, h:subview and h:dataTable. This is also standard JSF behaviour, and not myfaces-specific. In your example, there must be a few "naming container" components in the page, eg multiple forms or subviews. And the programmers of this app have not given fixed ids to these naming container components, so they get auto-assigned ids which their child components then inherit as their id prefix. Therefore in situations like yours where you need fixed ids for certain elements then the programmers MUST: (a) provide an explicit "id" attribute on each component which might be used in a unit test, and (b) provide an explicit "id" attribute on each "naming container" component In a project I worked on a few years ago, I wrote a small piece of code that was enabled during development to walk the jsf component tree at the end of each render phase, and log errors for components that did not have an explicit id. This was done specifically to allow the QA team to write Selenium scripts. The check was implemented as a JSF PhaseListener if I remember correctly. You might want to suggest that to the development team.. Regards, Simon
