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
>