Jeromy Evans wrote:
Brian Pontarelli wrote:
Besides that, I feel that everything else is fine and all we would be
adding would be features. Nothing else really needs to be completely
changed, but these two changes would impact applications that are
already built on SmartURLs and codebehind.
So, if I bang out this specification, which would include the
existing functionality with the changes above and a few other things
I want to add in terms of features (i.e. searching / interceptors /
defaults / exceptions / etc), would you feel comfortable writing the
book against that?
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.
ie. http:///www.example.com/invalid/path/to/resource currently maps
to the IndexAction at / (incorrectly?)
Yeah, that shouldn't happen because it doesn't currently look up the
hierarchy of packages. Not sure why this is happening, but it
definitely seems strange. Here's a not so great handling of missing actions:
http://www.texturemedia.com/invalid/index.action
It is a 500, which is due to the exception thrown from the ActionProxy.
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.
My point is, it's currently ambiguous how these exceptions should be
handled. Between these and the issues already in the issuelist, my
experience with SmartURLs 0.18 hasn't yet been positive except in the
simplest of use-cases. I do feel the approach is great and needed
though and I'm looking forward to the enhancements.
I'm somewhat surprised, but definitely willing to fix this stuff if we
can reproduce it. All of the cases you have mentioned work fine in all
of the applications I've built to
date so any code examples would be helpful.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
