I agree with Adam here... but this is one specific use case.. are there others?
Adam wrote:
===========================================================
IMO, Shale is wrong here, and always has been. The code
relies on non-portable behavior.
Shale remoting can work around this by:
- Changing managed bean names to meet the schema
- Adding a custom VariableResolver/ELResolver to handle
mapping the old names to the new objects
-- Adam
Imre Oßwald wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> 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