dev@javaserverfaces.java.net

Re: Issue with new validation scheme in HEAD

From: Imre O▀wald <io_at_mx.jevelopers.com>
Date: Thu, 17 May 2007 19:48:27 +0200

These are all valid points (especially the hierarchies one,
concerning the
developer confusion, I think most of the managed-beans with 'dots' in
their
names are normally not meant to be used in EL).

IMHO the problem is, that shale-remoting (which contains a managed-bean
with dots in its name) is used by other frameworks, so all these have
to be
updated too. And a application-developer has to be aware, that if he
updates
to the next RI-1.2 his application could break.

Probably having a relaxed schema for 1.0/1.1 configs would then be the
way to go?

-- Imre


On 17.05.2007, at 19:03, Adam Winer wrote:

> IMO, the original intent was always to support strict bean
> names. Period should be reserved. For one reason, it could be
> used later for creating hierarchies of beans. I also think it's
> extremely confusing if developers type a managed bean name like
> "foo.bar" but:
>
> DOESN'T WORK #{foo.bar.text}
> DOESN'T WORK #{requestScope.foo.bar}
> DOES WORK #{requestScope['foo.bar']}
>
> I can't think of an EL syntax that will retrieve one
> of these beans without knowing the scope its in.
>
> I also remember a recent bug filed over here at Oracle
> where a user had a managed bean named something like
> "foo-bar". Of course, #{foo-bar} means "foo minus bar".
>
> I think Shale should change.
>
> -- Adam
>
>
> Ryan Lubke wrote:
>> David M. Lloyd wrote:
>>> On Thu, 17 May 2007 08:32:16 -0700
>>> Ryan Lubke <Ryan.Lubke_at_Sun.COM> wrote (quoting Craig):
>>>
>>>
>>>> [...]
>>>> The spec language doesn't say anything, but the JSF 1.1 DTD comment
>>>> regarding <managed-bean-name> includes the comment 'It must be of
>>>> type "Identifier"', which references back to a "type description"
>>>> above claiming that the content must conform to the syntax of a
>>>> valid
>>>> Java identifier. I suspect that, when this DTD was translated
>>>> into a
>>>> schema, this requirement was taken literally.
>>>>
>>>> That creates an interesting backwards compatibility problem for
>>>> Shale, but also an interesting spec question regarding backwards
>>>> compatibility ... the RI for 1.2 is enforcing a requirement that
>>>> the
>>>> RI for 1.1 did not enforce, which could be argued is a breakage.
>>>> But, in the mean time, I'm going to look at what the impact
>>>> would be
>>>> of correcting these names in Shale.
>>>
>>>
>>>> We haven't released these changes yet, so this has no immediate
>>>> impact, but it would be good to get a discussion going on this and
>>>> figure out what should be done.
>>>>
>>>> For those of you on the EG, what do you think? Should the 1.2
>>>> schema
>>>> be relaxed?
>>>>
>>>
>>> Not personally on the EG, but relaxing the schema has my vote, 110%.
>>> No downside that I can see, and that behavior is, well, kind of
>>> obnoxious. :-)
>>>
>> EG or not, all feedback is welcome. The ultimate decision of
>> course is with them.
>>> - DML
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail: dev-
>>> help_at_javaserverfaces.dev.java.net
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-
>> help_at_javaserverfaces.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>