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
