Re: [Trinidad] forbidden binding names

[Renzo Tomaselli]

Well - I admit was a bit unlucky to meet one of them - but after all calling "param" a parameter shouldn't be too naif. In the context of iterating components - param, header, cookie and view might be dangerous names. All the others are quite unlikely to be used this way. Hopefully this game is not related to *any* variable resolution, e.g. I hope "foo.param" does not meet the same trouble, otherwise all reserved names might lead to troubles soon or later. -- Renzo Adam Winer wrote: 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