Well, we could have a Set for the JSP predefined values as well as JSF ones, but the problem is still going to happen when/if there's another unknown Variable/ELResolver installed. So, we do know the standard predefined objects, but not library predefined ones (except for Trinidad of course), hence why I think the doc should mention the issue more clearly.
On 8/1/07, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > Well, I know from earlier tests that setting var="person" if you have > a scoped bean named "person" will bring you into trouble as well - so > this is not only related to the predefined values. > > regards, > > Martin > > On 8/1/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > > > > > > > > > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
