Well, we do know the predefined objects: pageContext servletContext session request response param paramValues header headerValues cookie initParam pageScope requestScope sessionScope applicationScope facesContext view
Plus in Trinidad requestContext pageFlowScope/processScope All of these are bad news. It wouldn't be too rough to have a little trinidad-impl Set<String> of these, check against it in all the renderers + tags that expose "var" or "varStatus" and log a warning. Not 100% bulletproof, but it'd save someone a day of debugging some day. -- Adam On 8/1/07, Simon Lessard <[EMAIL PROTECTED]> wrote: > That's a nice issue, and we have no way to provide all the reserved names > either... I guess the best we could do is alter the parameter description to > mention that it must not take the value of any predefined object and should > not take the name of a managed bean either. > > Anyone see a better solution for this? > > > Regards, > > ~ Simon > > > On 8/1/07, Renzo Tomaselli < [EMAIL PROTECTED]> wrote: > > Hi, I just discovered that there are a number of names which cannot be > > used for binding iterating component variables - such as in tr:table. > > In short, I needed to render a set of parameters in a tr:table, so that > > it seemed obvious to me setting var="param". > > But the table was rendered empty, event if I have some other similar > > examples running fine. > > It took an entire day of hard debugging to discover that in > > org.apache.myfaces.el.VariableResolverImpl there are > several "trapping" > > names - "param" among the others. They prevent regular binding > > resolution, although no error is reported. Replacing "param" by anything > > else made the table being rendered fine. > > Just sharing to avoid anybody else to fall into the same trouble. > > > > -- Renzo > > > > > >
