On 3/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 3/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > > > > On Mar 21, 2006, at 4:45 PM, Gary VanMatre wrote: > > > > > I suppose that the choice of the context object could favor action > > > versus shale for a test framework. > > > > > > Since I'm in the JSF fan club, I'd argue that we could implement > > > the ExternalContext interface since the JSF API will soon be a given. > > > > I haven't thought about implementing it directly. That's > > interesting. I'd proceed cautiously though. My thinking (hope this > > is not news to anyone) is that Standalone Tiles will eventually just > > be "Tiles" :-) As such I hope it is useful to everyone who is > > currently using Tiles, including Struts Action, WebWork, etc. I > > wouldn't want to do anything that would make this impossible, or even > > difficult. At the same time I don't want to reinvent (or subclass) > > the wheel so I'm open to ideas. > > > For a library claiming to be "standalone", I would be a little cautious > about depending on either set of mock object APIs. That being said, the > Shale test framework mock objects for servlet and JSP stuff can be used > even > without JSF in the picture, so it might be a practical choice after all. > But you certainly would not want to program directly to any JSF APIs here.
I've heard a lot of good things about EasyMock, although I haven't used it myself. http://www.easymock.org/ Greg > > > > PS: Not to open up another tanker of worms, but is it possible to be > > in the the JSF and action fan club at the same time? Hmmm. > > Conflicted, I am. > > > It *looks* quite possible to get *some* combinations of benefits, with a > couple of different approaches: > > APPROACH 1: > > For example, Shale offers an applicaton controller (implemented as a > Filter) > that lets you use Commons Chain to define the global pre- and post- > processing that is done on every request (the sort of change you would > implement by modifying RequestProcessor in 1.1/1.2, or the global chain > implementation in 1.3). On my list of things to investigate is whether > that > could be substituted out for a gadget that uses XWork (the action > processing > framework that underlies WebWork) to gain access to the cool intercepter > stuff. > > The other place that you'd want to hook in is the equivalent of where your > action's execution method gets called, so you can decorate individual > logic > paths with local customizations. Turns out that JSF lets you customize > that > as well, so we can do the same sort of trick here. > > Jason/Patrick/Don/Ted/Martin -- are any of you guys going to be at TSSJS > later this week? I'd sure like to sit down and walk through whether this > is > as feasible in code as it appears to be on the back of a napkin. Sadly, no. My employer appears to be increasingly stingy on conferences this year. ;-( -- Martin Cooper APPROACH 2: > > Use the struts-faces library, and focus on just using the components parts > of JSF while using the framework part from Struts. If you look at the > internal architecture it ends up looking a little odd (the JSF front > controller is in front of the Struts front controller), but it can > actually > work. This is also a reasonable approach if you are required to migrate > an > existing Struts based app to JSF and cannot take the time to do it all > over > again. > > Craig > >
