Craig McClanahan wrote:
There are reasons to have an "application scoped" front controller.
There are reasons to have a "view-scoped" front controller. There is
*no* reason I am aware of that requires these controllers to be the
same :-).
Good point. In fact, I don't think it would take much to convince me
that it's better if they ARE NOT the same :)
In Shale, the application-scoped functions are performed by a Commons
Chain pipeline that is configured and processed by Shale's filter.
This is the right place to put things like "if the user isn't logged
on, redirect to the login page" and "log every request" type
functions. But it is not the right place for "execute this expensive
SQL query, but *only* if I am the view that needs it.".
This sounds very much like the types of things I would typically do in a
filter. I'm a fan of filters because it's one less piece of the
puzzle that doesn't tie me to a particular framework (I've done some
converting of apps from one framework to another, so I always keep the
possibility in mind as much as possible).
Is there a benefit to the Chain approach over filters?
In Struts 1.x, you get around the latter case, typically, by having a
setup action before the view, and a process action after the view.
Shale simply combines those two bits of code into a single class (and,
along the way, combining the form bean too), resulting in a little
less code, but a lot fewer classes.
I think I just realized why I'm not completely excited by this... I've
never been a fan of DispatchAction, and while I understand it isn't
exactly analogous, it is along the same lines.
You couldn't know just how ironic me saying that is, but trust me, it is
:) Probably 6 or 7 years back I had some rather heated debates with
some coworkers where I was trying to convince them it was better to have
a single class with a switch block than a couple of individual classes
(this was before frameworks were en vogue, so we were talking servlet
design). I've done a complete 180 on that, to the point where I,
generally, won't use DispatchAction.
It was, until now when I realized it, giving me a subconscious dislike
of anything along those lines :)
People do that with form beans already, so we clearly haven't
succeeded in communicating the correct pattern :-).
Agreed. And I for one cannot claim to have always gotten it right either :)
It's not about mixing layers. It is about mixing all the parts of the
*same* tier (view) related to a particular page into a single class,
instead of three classes (setup action, form bean, and process
action). The adapter has to be somewhere no matter what; co-hosting
it in a single class turns out to have benefits in terms of simplicity
and unit testability.
While I agree on the unit testability point, I'm not completely sold on
the simplicity argument... there's always a fine line between how much
actual code there is and how big the object hierarchy is. Go too far
either way and its complex, just in different ways. Again, I've changed
my opinion on this, but I now feel that a larger number of classes,
assuming each has a clearly defined role to play, is easier to digest
than a single class with all the code, or perhaps even a little more
code, in it. Again, there is a bit of a fine line there because if
there are too many classes, no matter how simple, it becomes difficult
to see how they all fit together.
In 1.1 and 1.2 JDKs (i.e. when Struts was invented), this mattered a
*lot*. In 1.4 JDKs, it basically doesn't matter unless you have
*huge* request volumes. Thus, the reasons for most people to not put
their adapters in request scope is basically gone.
That's good info, thanks! :)
I wonder, and I'm not the first one I'm sure, what would it take to make
Struts work that way now? More importantly, what would the consequences
be? It seems like it could be done in a completely backwards-compatible
way, at least at first pass through my brain.
Just remember ... the lifetime of Struts 1.x (five years since initial
conception, four years since 1.0) is basically a geologic era in terms
of Internet time :-).
Absolutely! You must have gotten *something* right for Struts to have
this kind of staying power :) I can think of many things that seemed
like the greatest thing since sliced bread at the time that wound up
fading into obscurity in half that time.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
