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.
ie. http:///www.example.com/invalid/path/to/resource currently maps to
the IndexAction at / (incorrectly?)
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?)
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.
regards,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
