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
>
