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 2) pages.login.UserLogin
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? 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]
