On 6/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
ok, I see. Thanks Ben for this important information.
But what happens, for example if I have the following structure:
2) pages.login.admin.AdminLogin
There's an outstanding bug for this, a case I didn't consider. It need
sto do something consistent here, but I'm not sure what.
2) pages.login.UserLogin
Would become "login/User".
I have not tried but I guess the second one becomes: login/User, which is reasonable. But what
about the first: "login/???"? Thus, the only workaround I can see to preserve the name is
to rename it to "pages.login.administration.AdminSignIn" which is strange to me and a
source for errors, to be honest...
Now I know there is some naming magic going on how can I "calculate" the
internally used URL for a given class? Otherwise it seems not (easily) possible to
forward to another page from within a RequestFilter by just using a Class's name instead
of a hardcoded (simplified) URL to that class. As soon the destination class is renamed
or moved the hardcoded URL is broken which could be prevented by deriving the URL from
the destination Class at runtime. Is there any way to achieve this?
Increasingly, looking for ways to do this in a refactoring safe way.
The PageLink component is the weak link in the chain, since its page
parameter is the logical name of the page. Almost everything else can
now be done without references to the logical page name, just the
actual page class.
Thanks in advance
Jens
>>>That is deliberate, not a bug.
From "New And of Note" at
http://tapestry.apache.org/tapestry5/tapestry-core/index.html
<quote>
The mapping from class names to page names (or component types) has been
tweaked to remove some redunancy; For example, class
org.example.myapp.pages.edit.EditUser will now have the name "edit/User"
rather than "edit/EditUser". This results in shorter, clearer, more
natural URLs
</quote>
cheers,
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
