And if you can't modify the bean to resolve the ambiguity? :)
It's an interesting idea, but I think it has too much potential for confusion +
backwards-compatibility issues. Frankly, I'm not super keen on the page-name
stripping, but I can tolerate that because they are tapestry pages behaving in
tapestry ways. "Property" has a very specific definition in the java language
and spec, and I think it's a bad idea for Tapestry to change that definition
for the sake of a few characters.
Robert
On May 25, 2011, at 5/253:46 PM , Lenny Primak wrote:
> I think in this particular case the bean should fail as being ambiguous ie
> multiply defined property.
>
>
>
> On May 25, 2011, at 4:35 PM, Josh Canfield <joshcanfi...@gmail.com> wrote:
>
>>> This is such an extreme example and can be easily caught - I.e. Tapestry
>>> can say ambiguous/duplicate property' or some such.
>>
>> :) I'm all about the edge cases. In this case the OP doesn't get to
>> define his beans so he's going to have to fall back to some other
>> method of accessing that field. You can do ${order.getDescription()}
>> or define a component property for instance. An error is required
>> though, ${order.description} needs to fail if
>> ${order.orderDescription} is valid.
>>
>> Josh
>>
>> On Wed, May 25, 2011 at 12:54 PM, Lenny Primak <lpri...@hope.nyc.ny.us>
>> wrote:
>>> This is such an extreme example and can be easily caught - I.e. Tapestry
>>> can say ambiguous/duplicate property' or some such.
>>>
>>>
>>>
>>> On May 25, 2011, at 2:27 PM, Josh Canfield <joshcanfi...@gmail.com> wrote:
>>>
>>>>> class Order {
>>>>> public String getOrderDescription();
>>>>> public String getDescription();
>>>>> }
>>>>>
>>>>> Tapestry could simply work as it does today and not apply property
>>>>> prefix stripping.
>>>>
>>>> This example is exactly why you would not want tapestry to do this. If
>>>> someone changes your bean definition now all of your templates are
>>>> broken, but not broken in a way that tapestry can tell you about but
>>>> in a way where the template is now getting data from the wrong
>>>> field...
>>>>
>>>> I suppose you have the same problem if you have an
>>>> app.pages.order.OrderPage and an app.pages.order.Page, but that seems
>>>> less scary to me.
>>>>
>>>> Josh
>>>>
>>>> On Wed, May 25, 2011 at 10:29 AM, Adam Zimowski <zimowsk...@gmail.com>
>>>> wrote:
>>>>> In the project I'm working on, I don't have control over Bean design,
>>>>> so this would be nice to have.
>>>>>
>>>>> Also, for beans like this one:
>>>>>
>>>>> class Order {
>>>>> public String getOrderDescription();
>>>>> public String getDescription();
>>>>> }
>>>>>
>>>>> Tapestry could simply work as it does today and not apply property
>>>>> prefix stripping.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>>
>>>>> On Wed, May 25, 2011 at 12:20 PM, Lenny Primak <lpri...@hope.nyc.ny.us>
>>>>> wrote:
>>>>>> At first glance, seems like a fantastic idea!
>>>>>>
>>>>>> On May 25, 2011, at 1:19 PM, Adam Zimowski wrote:
>>>>>>
>>>>>>> Since Tapestry already does tricks to clean up URL naming redundancy,
>>>>>>> it would be nice if it did the same with the expression language. For
>>>>>>> example:
>>>>>>>
>>>>>>> // Bean
>>>>>>> class Order {
>>>>>>> public String getOrderDescription() {...}
>>>>>>> }
>>>>>>>
>>>>>>> // Page
>>>>>>> public Order getOrder() {
>>>>>>> //...
>>>>>>> }
>>>>>>>
>>>>>>> // TML
>>>>>>> Instead of having to say this: ${order.orderDescription}
>>>>>>>
>>>>>>> Perhaps this: ${order.description}
>>>>>>>
>>>>>>> Yes? No?
>>>>>>>
>>>>>>> Adam
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
