Brian Pontarelli wrote:
Jeromy Evans wrote:
While on the topic, with respect to defaults/exceptions etc, can I
ask the specification addresses how invalid URLs are handled. In the
current implementation (0.18) invalid URL's return (unexpected?)
success results.
They shouldn't unless it finds a result that will handle the URL. If
it can't find one it will throw the standard exception, which should
be processed as it currently is. I've tested default actions/results
as well as exception and 404/500 handling and it all works fine. If
you could give an example that is not working for you, I can look into
it.
I see. In my case as I had an IndexAction in the base package and a
result for the success result (/index.jsp) and no default action,
instead of generating a 404 when entering an arbitrary path, it executes
the root IndexAction (the index action in the default package).
In the case of MailReader, if you enter
http://localhost:8080/an/arbitary/url it will attempt execute the
default action (Support) but returns a 404 because no result corresponds
to SUCCESS. This case seems okay as a default action was defined and
subsequently executed.
My case can be replicated in the MailReader however by adding a no-op
IndexAction in root namespace and removing the default-action-ref.
After making this change:
http://localhost:8080/index shows the index
http://localhost:8080/an/arbitary/url also shows the root index
and after showing the index for an arbitrary URL, all relative links
become invalid:
ie. clicking on "Log into MailReader" successfully performs a GET to
http://localhost:8080/an/arbitary/url/login-input/ and shows the index again
Namespace precedence also seems to be an issue when handling invalid
paths and needs to be specified:
ie.
Assuming pets.IndexAction exists:
http://www.example.com/pets maps to pets.IndexAction (as
expected); but the URL:
http://www.example.com/pets/dogs maps to /IndexAction if
pets.dogs.IndexAction does not exist rather than pets.IndexAction or
an exception (which is expected?)
This is a bit confusing. So, /pets should redirect /pets/ and that
should render the /pets/index action. However, /pets/dogs should error
out unless there is an action named dogs in /pets or an index action
in /pets/dogs. If that isn't working it seems like a bug.
Here's the same example in the unmodified MailReader:
Register a user and login:
GET http://localhost:8080/register/update!input allows you to edit your
current profile (okay)
GET http://localhost:8080/register/ shows the root index page (the one
at /index) (not okay)
GET
http://localhost:8080/register/login-input/register/login-input/register/login-input/
shows the root index page (not okay)
GET http://localhost:8080/register/update!input/login redirects to GET
http://localhost:8080/register/update!input/menu (not okay)
GET http://localhost:8080/subscribe/update!input/logout redirects to GET
http://localhost:8080/subscribe/update!input/index (not okay)
It seems to be a bit too eager matching actions in the root namespace.
Anyway, I wasn't intending to raise bugs. As I mentioned already, I
think this is going to be a great change, but the exception handling and
defaults need to be examined a little closer.
Hope that helps,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
