On Wed, Jan 01, 2003 at 12:36:38PM +0100, Rickard Öberg wrote: > Chris Nokleberg wrote: > >I think it would be more useful if instead of applying directly to > >actions, the filters/interceptors applied to paths (URLs). The paths > >could support wildcards, either Servlet-style or a more complete regexp > >style. e.g. > > The problem is that people will then start naming their pages in order > to make it easy to apply filters. And that's bad. URL's should not > reveal the underlying technology, and should be as long-lived as > possible. Also imagine if you have a page that is initially unsecured, > but after a while you see that it needs to be secured. Will you then add > its path to the configuration or move it to /secure? Probably the > latter, and you then broke all bookmarks to it. > > Nah, there's gotta be a better way.
This is probably mostly a philosophical discussion, but... If the URL hierarchy reflects the structure of the application(*), I think many cross-cutting aspects such as persistence and security will be very cleanly expressed as URL patterns. You'll notice in my example I used "/admin" instead of "/secure", because I agree that the URLs should reflect the content more than the implemention. However, often there will be a strong correlation. There may be cases where you need to change "one page", and hopefully this would be fixable by adding a pattern that matched that URL exactly, overriding the old behavior. If you're changing too many pages, however, it seems likely that your URL structure no longer will have any logical meaning. And that's bad. While we're on the subject of URL design, it is also bad to have every action end in ".do" or whatever. This is an artificial requirement imposed by the framework (and the sucky servlet 2.2 spec). At least a Filter-based controller should be provided as an alternative to the current Servlet one; this would allow servlet 2.3-compatible container users to map actions to any URL. -Chris * http://www.useit.com/alertbox/990321.html ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork