On Wed, Jan 01, 2003 at 07:17:15PM +0100, Rickard Öberg wrote:
> Chris Nokleberg wrote:
> >If the URL hierarchy reflects the structure of the application(*),
>
> Which it IMHO shouldn't.
What else would it reflect? I'm not being surly, I really am curious.
> >I
> >think many cross-cutting aspects such as persistence and security will
> >be very cleanly expressed as URL patterns.
>
> It may "kind of" work for those, but then there's the transactional
> aspect for example. Would you introduce a /tx part in the URL?
Maybe there are some aspects which are better tied to the actions
themselves. Whether an action is transactional is intimately related to
the actual code in the execute() method, after all. There are others
that are much more orthogonal to the action. Perhaps the code that
builds the interceptor chain for a request could have multiple inputs.
> And
> again, what if you first have a non-tx page and then decide to make it
> transactional, what happens then? "oh sorry, all bookmarks to this page
> broke because we decided to make it transactional".
This seems a bit disingenuous--I explicitly recommended against breaking
bookmarks. The right way would be to overriding the interceptor mapping
for that page.
> And how about if
> there are two apps on one page? What do you do then?
Presumably that could be inferred from the URL also (one would
hope). Anyway, you don't have to limit yourself to prefix or extension
mapping.
But the core idea is that there are at least some aspects that are
better applied to URLs than to the actions themselves. Security is a
very good example; J2EE declarative security doesn't map roles to
individual servlets, after all--it uses URL mappings.
> Nah. It's just a bad idea.
>
> >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.
>
> I agree that using .action URL's as the top-level URL is a bad idea. It
> works quite ok for includes though, since it's hidden from the user.
>
> And yes, a filter-based controller might be the right way to go in some
> cases, although only for read-only pages. E.g. if you have an action
> which can result in two different pages you need to refer to the
> ".action" URL which then can result in one of several pages to be
> included as the actuL HTML response.
I don't follow you. My conception was that the filter controller would
often be the end-point of requests, much like the current servlet
controller is. The big difference is that the filter *can* let through
requests to pages which do not have an action mapping. e.g.
if (haveActionMapping(request)) {
handleRequest(request, response);
return;
} else {
chain.doFilter(request, response);
}
A filter-based controller is technically strictly better than a
servlet-based one, except for backward-compatibility.
-Chris
-------------------------------------------------------
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
