Re: [OS-webwork] Rethink

[Rickard Öberg]

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.

Ok, what I meant was that it shouldn't reflect the implementation of the application. Because implementations change. Tying action behaviour to paths would be one way that the implementation might be reflected too much in URL's. Why? Because it would be easy. And a bad idea.

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.

True, but also other factors, such as runtime environment and the setup of the persistence mechanisms.

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.

What do you mean by multiple inputs?

I think tying the interceptor chain to the action name would be the simplest and most effective way. By using reusable "stacks" information redundance can be kept at a minimum.

In my own AOP framework I have another way to deal with it. For example, *all* methods have the transactional interceptor, but it is only *triggered* if that method has a runtime attribute "transaction" defined. This makes it easy to declare, since basically methods have the same stack, but at the same time the *actual* behaviour depends on the actual method being invoked.

It would be great to be able to do the same thing here, but then I'd have to replicate the runtime attribute framework, which seems a little silly at this point.

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.

Problem is: the right way is not the easy way, and developers tend to prefer the easy way.

Presumably that could be inferred from the URL also (one would
hope).

What if there are ten apps on the page? This is, for example, not unlikely in portal-style sites, such as the one I'm working on.

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.

IMHO J2EE declarative security sucks. But that's just me. It's just really backwards. Our own product declares permissions that are needed for a portlet/(servlet), and then roles and users can be assigned that permission. The problem with J2EE declarative security is that since it's static it's a bad idea to assign roles, since roles change. Much better to assign permissions and then say "this roles includes this permission" and then assign users to those roles. It scales a heck of a lot better.

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);
  }

Ok, I see.

A filter-based controller is technically strictly better than a
servlet-based one, except for backward-compatibility.

I would agree, especially if we do it the way I outlined, i.e. URL's are associated with actions *by the app itself* which are then triggered when the URL is accessed.

/Rickard

--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic

Got blog? I do. http://dreambean.com



-------------------------------------------------------
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