myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: Generation strategy of the j_id prefixes?
Date Tue, 09 Sep 2008 13:25:51 GMT
Hi Felix,

Felix.Becker@t-systems.com 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


Mime
View raw message