On Nov 1, 2007 6:34 PM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > While on the topic, with respect to defaults/exceptions etc, can I ask > the specification addresses how invalid URLs are handled.
The specification implies that the implementation should raise a 404. > 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?) So far, treating the namespaces as a hierarchy has not been the expected behavior. Struts 2 checks the current namespace for a result, and then the default (empty) namespace. So the behavior you describe is consistent with the rest of Struts 2. Although, as mentioned elsewhere, viewing the namespaces as a hierarchy may be more useful. > 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. Could you be more specific as to what enhancements would be the most useful? I find that making the best use of SmartURLs does mean taking a fresh look at the application, and sometimes refactoring the layout, much the same way we sometimes refactor a database schema to work better with ORM systems, like Hibernate or JPA. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
