On Mon, 22 Nov 2004 18:55:36 -0600, Joe Germuska wrote:
From
http://sourceforge.net/projects/strutstestcase/ I see that there
are four developers (including Ted) but I don't see a way to gauge
the involvement of them.
I was the first developer that Deryl added, which was a little over a
On Tue, 23 Nov 2004 09:30:20 -0800, Martin Cooper wrote:
struts-chain is in struts/sandbox/trunk, yes, and it will likely be
moved into struts/core/trunk as part of Struts 1.3. However, since
we instituted a policy of not depending on any other components
that are unreleased, that's not going
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=17306.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=14471.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
It sounds like StrutsTestCase could really take advantage of AOP. The
whole notion of injecting a custom request processor to intercept the
returned forward could be handled by an aspect.
-Bill Siggelkow
Ted Husted wrote:
On Mon, 22 Nov 2004 18:55:36 -0600, Joe Germuska wrote:
From
Craig McClanahan wrote:
On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska [EMAIL PROTECTED] wrote:
I need to have a hook into processValidate() on validation failure.
Currently that can only be done by copy-and-pasting the processValidate()
method from RequestProcessor into a subclass and
On Wed, 24 Nov 2004 11:03:23 -0700, BaTien Duong
[EMAIL PROTECTED] wrote:
[snip]
3) CoR is finer grain than IoC in the construction and rounting of
services within and between software layers, while IoC is aprropriate at
the application level.
I don't think of these as mutually exclusive.
Not you personally BaTien, I don't understand why some people seem to
confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
and worse, think they are somehow solving the same problem. IoC helps
us create components by managing their lifecycle and providing their
dependencies.
Without disagreeing with anything you have said, Don, I think the
confusion is caused in part by the fact that CoR is anticipated in
part for its pluggable nature. In this respect, there is a real
connection in functionality between CoR and IoC that is not as
attenuated as the one between HashMap
I look at technology as solutions to problems. IoC solves the problem
of how can I define and configure a component external to the component
and calling code, and CoR tackles the problem of a how can I define a
process or sequence of processes in a pluggable manner.
True, both patterns have
Craig McClanahan wrote:
On Wed, 24 Nov 2004 11:03:23 -0700, BaTien Duong
[EMAIL PROTECTED] wrote:
[snip]
3) CoR is finer grain than IoC in the construction and rounting of
services within and between software layers, while IoC is aprropriate at
the application level.
I don't think of these
Don Brown wrote:
I look at technology as solutions to problems. IoC solves the problem
of how can I define and configure a component external to the
component and calling code, and CoR tackles the problem of a how can I
define a process or sequence of processes in a pluggable manner.
True,
Author: craigmcc
Date: Wed Nov 24 11:25:18 2004
New Revision: 106447
URL: http://svn.apache.org/viewcvs?view=revrev=106447
Log:
Implement the mechanism for application-wide controller actions (as described
in the original Shale proposal), by virtue of turning the filter's processing
into the
Author: craigmcc
Date: Wed Nov 24 11:26:19 2004
New Revision: 106448
URL: http://svn.apache.org/viewcvs?view=revrev=106448
Log:
Tweak the build script to pick up Commons Chain (which is now a dependency
for the core Shale classes), and the 1.1 version of the JSTL Standard Tag
Library (required
Is there any reason that a JSF-independent version of the
application-wide controller scheme, as just checked in, couldn't be
part of Struts 1.3? Or, for that matter, even part of the Commons
Filters component, or even Chain itself? It seems like a much too
useful general purpose filter to bury it
On Wed, 24 Nov 2004 11:44:04 -0800, Martin Cooper [EMAIL PROTECTED] wrote:
Is there any reason that a JSF-independent version of the
application-wide controller scheme, as just checked in, couldn't be
part of Struts 1.3?
That should work fine, as long as 1.3 is going to be based on Servlet
2.3
On Wed, 24 Nov 2004 11:53:00 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Wed, 24 Nov 2004 11:44:04 -0800, Martin Cooper [EMAIL PROTECTED] wrote:
Is there any reason that a JSF-independent version of the
application-wide controller scheme, as just checked in, couldn't be
part of
Craig McClanahan wrote:
On Wed, 24 Nov 2004 11:44:04 -0800, Martin Cooper [EMAIL PROTECTED] wrote:
Is there any reason that a JSF-independent version of the
application-wide controller scheme, as just checked in, couldn't be
part of Struts 1.3?
That should work fine, as long as 1.3 is
Author: husted
Date: Wed Nov 24 14:37:01 2004
New Revision: 106481
URL: http://svn.apache.org/viewcvs?view=revrev=106481
Log:
Add README and STATUS files to describe the subproject state.
Added:
struts/sandbox/trunk/mailreader-chain/README.txt
Where is this checked in. folks?
Jack
On Wed, 24 Nov 2004 11:44:04 -0800, Martin Cooper [EMAIL PROTECTED] wrote:
Is there any reason that a JSF-independent version of the
application-wide controller scheme, as just checked in, couldn't be
part of Struts 1.3? Or, for that matter, even part
On Wed, 24 Nov 2004 11:53:00 -0800, Craig McClanahan wrote:
It's also a shame that you guys are so focused on the current
version that you haven't had a chance to see the light about the
future too :-).
Given that JSF and ASPX are quite similar, you could say that I've been living
in the
On Wed, 24 Nov 2004 14:39:45 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
Where is this checked in. folks?
We recently reorganized the repository so that independent pieces of
Struts could be branched and released independently of each other.
As a result, the SVN repository for the core of
Imports don't seem to show up on the SVN email logs, so I thought I'd point out
that a MailReader-Chain demonstration application has been checked in to the
sandbox.
This is something I started several months ago in the Commons Chain CVS. Now
that we are moving Struts to a Chain-based request
Well put, Sir. I think this about does it. I would advocate not
only the CoR coding now being done but also an eventual IoC using all
three types of injection for the major components in Struts. This
would be, I think, the cat's meow, or the tree's bark. /// ;-)
Jack
On Wed, 24 Nov 2004
24 matches
Mail list logo
