Jeromy Evans wrote:
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).
That is really strange. Smart URLs isn't involved in that process at
all. It simply creates actions for very specific mappings. I would guess
that this is something else handling execution of the root action. Send
me the configuration or create an issue with the configuration because
it definitely shouldn't be happening that way.
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.
Yeah, that makes sense.
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
Very odd. Might be something Ted added to mailreader, but this shouldn't
be happening and I'd like to figure out why it is.
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.
Yes it does seem very eager. I know that this doesn't occur in
applications that I've written that use only SmartURLs conventions with
no other configuration, so I'm starting to think this is a configuration
thing. But I'll definitely look at the mailreader and see if I can
figure this out.
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.
I'm intending to raise some bugs! ;) I definitely want to ensure that
things work as expected and right now SmartURLs shouldn't be doing any
type of root index handling at all.
Hope that helps,
It does! Thanks.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
