The bean can be proxies or wrapped in an extreme case. I am all for 99%
solution and like my baby but not the bath water.
On May 25, 2011, at 5:09 PM, Robert Zeigler <robert.zeig...@roxanemy.com>
wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
