Quoting Diego Louzán Martínez <[EMAIL PROTECTED]>: > Ok, I suppose this is a direct question to Craig as the maintainer > ofstruts-faces:I'm studying JSF and I need to integrate a Struts > application with it,so I am studying struts-faces too. My problem is > that this applicationuses a custom RequestProcessor that implements the > ProcessingFilterpattern and in the *KNOWN LIMITATIONS* of struts-faces > it says that Ihave to subclass FacesRequestProcessor (I'm not using > Tiles). Thequestion is: ¿this behaviour is planned to be stable? ¿will I > have tochange the implementation later? I will also be grateful for some > adviceon how to do it.Thanks in advance. > --
For use with Struts 1.1, this behavior is indeed planned to be stable -- you should plan on subclassing FacesRequestProcessor (if you're not using Tiles) or FacesTilesRequestProcessor (if you are). As of the latest nightly builds of the struts-faces library, you specify your overridden class name in the usual way (with the <controller> element in struts-config.xml). At some point during the development of Struts 1.2 and 2.0, we'll switch our primary approach to something like commons-chain (see this package in the Jakarta Commons Sandbox, and the source code in the "contrib/struts-chain" directory of the Struts source archive, to get a feel for where we're going). At that point, you will be able to configure and customize your own processing chains based on the combination of technologies that you are using, without having to explicitly subclass a monolithic RequestProcessor base class. In terms of mechanics, it's really no different than subclassing the standard RequestProcessor -- simply create a class that extends the base one, and override the methods you need to change. You'll need struts-faces.jar on your compile classpath, of course. > Diego Louzán Martínez > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
