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
