Exactly the same can be said for URL de-duping.
On May 26, 2011, at 10:06 AM, Geoff Callender
<geoff.callender.jumpst...@gmail.com> wrote:
> -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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
