-1 for me. I can see it causing immense confusion in normal maintenance work
esp. when refactoring.
Geoff
On 26/05/2011, at 8:26 AM, Bob Harner wrote:
> Seems like unnecessary complexity to me.
>
> Bob Harner
> On May 25, 2011 5:51 PM, "Adam Zimowski" <zimowsk...@gmail.com> wrote:
>> Guys - it is interesting to see your perspectives, I appreciate this.
>> What if this could be a configurable setting?
>>
>> I have several beans like this and a very large app. Quite frankly,
>> it's become more than annoyance at this point. Besides, the TML code
>> is loaded with unnecessary prefixes and expressions do look redundant.
>> Even my designer CSS guru pointed this out, and he is clueless about
>> Tapestry :)
>>
>> I think if this was a configurable setting, turned off by default, the
>> fact that developer would go through the effort to turn it ON would
>> indicate he/she knows what he is doing and be aware of collision
>> pitfalls.
>>
>> Adam
>>
>>
>>
>> On Wed, May 25, 2011 at 4:27 PM, Martin Strand
>> <do.not.eat.yellow.s...@gmail.com> wrote:
>>> I agree with Robert.
>>>
>>> Also, the purpose of page-name stripping (as I understand it) was never
> to
>>> save a few characters when typing.
>>> It was to let page classes have unique and explicit names but still give
>>> them "pretty" URLs (where words are not repeated)
>>>
>>> /edit/user --> pages.edit.EditUser
>>> /edit/group --> pages.edit.EditGroup
>>> /edit/entity --> pages.edit.EditEntity
>>>
>>> or perhaps:
>>>
>>> /user/create --> pages.user.CreateUser
>>> /user/edit --> pages.user.EditUser
>>> /user/delete --> pages.user.DeleteUser
>>>
>>>
>>> On Wed, 25 May 2011 23:09:37 +0200, 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
