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