Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification

[Jeromy Evans]

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]