We need to reorganize/rationalize the Struts repository to better support subprojects, which would include something likeStruts TestCase.
The reorganization has been waiting on a stable release of 1.2.x, which has in turn been waiting on a stable release of the Commons Validator (for nearly three months now). After some brouhaha, I may finally be able to roll Validator 1.1.3 tomorrow night. We can then turn around and roll Struts 1.2.1. I was away last week, and will be away again next week, so hopefully we can wrap this up by Friday. Otherwise, unless someone else steps up to the plate, it may have to wait until July. :( Moving forward, we'd like to reorganize the project into several subprojects (core/taglibs/faces/whiteboard, et cetera), so that everything is not so easily blocked for the sake of a single dependency. I'd be happy to see StrutsTestCase, along with some other components like SSL, become Struts subprojects, and would welcome the donation of the StrutsTestCAse codebase. -Ted. On Fri, 11 Jun 2004 10:25:58 -0700, Deryl Seale wrote: > Hello, all. My name is Deryl Seale, and I am the maintainer of > the StrutsTestCase library. Some time ago, Ted Husted contacted me > about integrating StrutsTestCase into the Struts codeline, > effectively making it a part of the Struts offering. I've seen > this idea crop up a bit more on this list, and as well, I think it > would benefit StrutsTestCase by opening it up to a larger body of > developers. To that end, I thought I would broach the topic, and > get your collective thoughts on how best to pull in the > StrutsTestCase code. > > I've spent a good amount of time during the past year keeping apace > with Struts development, since StrutsTestCase needs to know about > the Struts internals to do its job. The major part of STC is > verifying that an Action returns an expected forward, which right > now comes down to comparing an expected to the actual forward path, > *not* the forward name. A bulk of the STC code contains > contrivances to get this information, and it works well.. to a > point. Extensions such as Tiles pose a problem, however, since the > path that is forwarded can be the same for many tiles, and so path > comparison breaks down. > > What I really need is some way to get the forward just as it's > returned from the Action, and the RequestProcessor seems to be the > answer. In fact, I've built a prototype where I "inject" my own > RequestProcessor into Struts, and in doing so, I can grab the > forward and use it for validation, which is much more robust than > path comparison; as well, it cuts out about half of the STC code > base, which is swell. Unfortunately, that approach only works if no > other RequestProcessor is used, since chaining of RequestProcessor > objects is not currently supported (which I know is a hot topic > right now) -- and that is not feasible for most Struts projects. > > So, anyway, that's where StrutsTestCase is right now, and I'd like > to get to the point where I can more reliably get inside Struts to > get the validation information I need. I like the idea of using > RequestProcessor, but there are obviously large architectural > changes required for that be a real solution. If there are other > ways to attack this problem, then I'd like to hear about them. And > finally, I'd like to hear your thoughts and suggestions for getting > StrutsTestCase to be a part of Struts. > > thanks. > --Deryl > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
