Craig McClanahan wrote:
It is a little simpler to use than filters (the programming interface for a
command is a *lot* simpler than for a Filter), and a bit easier to configure
as well.
Certainly an easier interface, although I'm not as sure about
configuration... although you get more *flexibility* with chains
(catalogs, subchains, dynamic flow alteration, looping, etc), so even if
filters are simpler to configure, chains are certainly more flexible,
which makes up for it.
> But the primary reason for a CoR based request processor (RP) is
to get rid of the restrictions of an RP implemented as a single class, where
the mechanism for specialization is a subclass. Java's single inheritance
makes it really difficult to combine more than one specialized subclass of
RequestProcessor into a single app.
No argument there... but the same could be said of filters :) It would
give you the same result as far as the RP goes.
If you already grok filters, go for it. But I can see a day coming where
even more people are going to bitch about having to edit web.xml files to
set up all the filter mappings :-).
I've done both filters and chains pretty extensively at this point...
I'm not sure why anyone would bitch any more about having to edit
web.xml vs. chain-config.xml :) Seems pretty comparable to me, and
arguably since everyone in the world (but me!) uses an IDE, and since
most of them these days have fancy little web.xml editors built-in, one
could argue it's even easier.
I probably lean towards chains myself based on nothing more than the
added flexibility they give you. In any case, I was just asking a
question for the sake of discussion, that's all. I'm sold on chains in
general anyway :)
Craig
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
