Craig,
Well, I definitely agree that any sort of auto-population is very, very
worrisome. But, using <value>#{param.foo}</value> for a managed
property still leaves behind some major problems:
- If the bean is request-scoped, it forces you to get this parameter
into every request - a major challenge for postback in JSF.
- You have to very carefully check incoming parameter values
for legitimacy (in a way that JSF components often can handle
automagically) since no validation will be performed by the system.
- Painful coupling between the target page, consuming the URL,
and the source page, generating the query parameter.
... which is why a good solution to the problem involves a really smart
navigation handler (plus other parts of a JSF system) that can automate
the generation of such URLs *and* the inteilligent consumption on the
target page.
-- Adam
On 1/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 1/28/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > [snip]
> > Now the phase listener has the convention, that "foo" and "bar" are
> > the bean properties
> > and populates the bean with the given values.
>
> If the destination bean is itself a managed bean, you can actually avoid
> this restriction, by allowing the bean itself to configure capturing
> interesting request parameters with an expression like this in a <value>
> element:
>
> #{param.foo}
>
> #{param.bar}
>
> This would also avoid cases where the backing bean just happens to have a
> property with the same name as one of the request parameters, which will get
> modified by your logic (and could lead to a variety of DOS attacks by
> clients that add spurious parameter values).
>
> Craig
>
>
