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
