> 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
