You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Adam Zimowski <zi...@gmail.com> on 2011/05/25 19:19:01 UTC
T5: property expression language intelligence
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Taha Hafeez <ta...@gmail.com>.
Hi
Seems like a good idea.
These are side-effects of tapestry. It makes you very lazy :)
regards
Taha
On Wed, May 25, 2011 at 10:59 PM, Adam Zimowski <zi...@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 <lp...@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-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: property expression language intelligence
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
The bean can be proxies or wrapped in an extreme case. I am all for 99% solution and like my baby but not the bath water.
On May 25, 2011, at 5:09 PM, Robert Zeigler <ro...@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 <jo...@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 <lp...@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 <jo...@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 <zi...@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 <lp...@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-unsubscribe@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Exactly the same can be said for URL de-duping.
On May 26, 2011, at 10:06 AM, Geoff Callender <ge...@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" <zi...@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...@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
>>>> <ro...@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 <jo...@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 <lprimak@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 <jo...@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 <
>> zimowski74@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
>>>>>>>>>> <lp...@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Howard Lewis Ship <hl...@gmail.com>.
I understand where you are coming from, but I can't see this in the core.
Robert identified my thinking at the time I introduced the naming aliases,
and even that's a bit controversial.
On Thu, May 26, 2011 at 3:58 PM, Adam Zimowski <zi...@gmail.com> wrote:
> No prob. I'll just hire intern monkeys to do all that unnecessary
> typing for me :-)
>
> Just kidding. Thanks for your feedback.
>
> On Thu, May 26, 2011 at 9:44 AM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> On Thu, 26 May 2011 11:06:44 -0300, Geoff Callender
>> <ge...@gmail.com> wrote:
>>
>>> -1 for me. I can see it causing immense confusion in normal maintenance
>>> work esp. when refactoring.
>>
>> -1 to me. The less to understand, the better.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and
>> instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: T5: property expression language intelligence
Posted by Adam Zimowski <zi...@gmail.com>.
No prob. I'll just hire intern monkeys to do all that unnecessary
typing for me :-)
Just kidding. Thanks for your feedback.
On Thu, May 26, 2011 at 9:44 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Thu, 26 May 2011 11:06:44 -0300, Geoff Callender
> <ge...@gmail.com> wrote:
>
>> -1 for me. I can see it causing immense confusion in normal maintenance
>> work esp. when refactoring.
>
> -1 to me. The less to understand, the better.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 26 May 2011 11:06:44 -0300, Geoff Callender
<ge...@gmail.com> wrote:
> -1 for me. I can see it causing immense confusion in normal maintenance
> work esp. when refactoring.
-1 to me. The less to understand, the better.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Geoff Callender <ge...@gmail.com>.
-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" <zi...@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...@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
>>> <ro...@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 <jo...@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 <lprimak@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 <jo...@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 <
> zimowski74@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
>>>>>>>>> <lp...@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Bob Harner <bo...@gmail.com>.
Seems like unnecessary complexity to me.
Bob Harner
On May 25, 2011 5:51 PM, "Adam Zimowski" <zi...@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...@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
>> <ro...@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 <jo...@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 <lprimak@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 <jo...@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 <
zimowski74@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
>>>>>>>> <lp...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: T5: property expression language intelligence
Posted by Adam Zimowski <zi...@gmail.com>.
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...@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
> <ro...@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 <jo...@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 <lp...@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 <jo...@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 <zi...@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
>>>>>>> <lp...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Martin Strand <do...@gmail.com>.
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
<ro...@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 <jo...@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
>>> <lp...@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 <jo...@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
>>>>> <zi...@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
>>>>>> <lp...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Robert Zeigler <ro...@roxanemy.com>.
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 <jo...@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 <lp...@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 <jo...@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 <zi...@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 <lp...@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-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
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 <jo...@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 <lp...@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 <jo...@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 <zi...@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 <lp...@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-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Josh Canfield <jo...@gmail.com>.
> 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 <lp...@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 <jo...@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 <zi...@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 <lp...@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-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
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 <jo...@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 <zi...@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 <lp...@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Josh Canfield <jo...@gmail.com>.
> 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 <zi...@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 <lp...@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Adam Zimowski <zi...@gmail.com>.
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 <lp...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: property expression language intelligence
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org