HAPPY THANKSGIVING :-D

Best wishes for a fantastic, SAFE, FUN, holiday to all of you that celebrate it :-) ... and for those that don't, feel free to eat, drink, and be merry anyway! ;-) HAPPY THANKSGIVING! :-D Eddie --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0448-0, 11/23/2004 Tested on:

Re: Shale application-wide controller

On Wed, 24 Nov 2004 18:32:26 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Well, I have probably Bozoed! I clicked on my sandbox repository and > updated with TortoiseSVN. However, I see nothing like what I thought > was being discussed here. Where would I see it and what is it called? > Soun

Re: Shale application-wide controller

Well, I have probably Bozoed! I clicked on my sandbox repository and updated with TortoiseSVN. However, I see nothing like what I thought was being discussed here. Where would I see it and what is it called? Sounds like a snipe hunt? ;-) Jack On Wed, 24 Nov 2004 14:51:33 -0800, Craig McClan

Re: Chain enhancement idea

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 200

MailReader-Chain (was Re: svn commit: r106481)

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 p

Re: Shale application-wide controller

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 S

Re: Shale application-wide controller

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 fu

Re: Shale application-wide controller

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 p

svn commit: r106481 - /struts/sandbox/trunk/mailreader-chain/README.txt /struts/sandbox/trunk/mailreader-chain/STATUS.txt

Author: husted Date: Wed Nov 24 14:37:01 2004 New Revision: 106481 URL: http://svn.apache.org/viewcvs?view=rev&rev=106481 Log: Add README and STATUS files to describe the subproject state. Added: struts/sandbox/trunk/mailreader-chain/README.txt struts/sandbox/trunk/mailreader-chain/STATUS.tx

Re: Shale application-wide controller

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 goi

Re: Shale application-wide controller

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

Re: Shale application-wide controller

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

Shale application-wide controller

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

svn commit: r106448 - /struts/sandbox/trunk/struts-shale-mailreader/build.xml /struts/sandbox/trunk/struts-shale-mailreader/src/web/subscription.jsp

Author: craigmcc Date: Wed Nov 24 11:26:19 2004 New Revision: 106448 URL: http://svn.apache.org/viewcvs?view=rev&rev=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 fo

svn commit: r106447 - in struts/sandbox/trunk/struts-shale: . src/conf src/java/org/apache/shale/faces

Author: craigmcc Date: Wed Nov 24 11:25:18 2004 New Revision: 106447 URL: http://svn.apache.org/viewcvs?view=rev&rev=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 exec

Re: Chain enhancement idea

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

Re: Chain enhancement idea

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 thes

Re: Chain enhancement idea

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 a

Re: Chain enhancement idea

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

Re: Chain enhancement idea

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.

Re: Chain enhancement idea

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.

Re: Chain enhancement idea

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

Re: Experiences with MockObjects for Servlet testing?

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 http://source

DO NOT REPLY [Bug 14471] - [validator] validator-rules.xml JavaScript fails when field not present in jsp

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17306] - [validator] Extend tag with "forward" attribute for error page

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: chain in trunk for builds?

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 goi

Re: Experiences with MockObjects for Servlet testing?

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