1. „Create a new com.ibm.xsp.context.FacesContextExImpl!“
2. „Add all required classed to the build path!“
3. „Add a useless message to the constructor!“
4. „BUILD IT!“
5. „Open the original Jar!“
6. „In WinRAR!“
7. „Overwrite the existing classes!“
8. „Quick! Start the server!“
9. „And open a XPage!“
10. „Look! It is fulfilled!“
That is great!
Elijah
Why the hack? This is completely supported and can be found in the XspStarterKit project on OpenNTF. http://www.openntf.org/main.nsf/project.xsp?r=project/XSP%20Starter%20Kit
some.package.CustomFacesContextFactory
public class CustomFacesContextFactory extends FacesContextFactory {
private FacesContextFactory _delegate;
…
public FacesContext getFacesContext(Object context, Object request, Object response, Lifecycle lifecycle)
throws FacesException {
FacesContext ctx = _delegate.getFacesContext(context, request, response, lifecycle);
return new CustomFacesContext(ctx);
…
public class CustomFacesContext extends DominoFacesContext {
public CustomFacesContext(FacesContext paramFacesContext) {
super(paramFacesContext);
…
Because the voices in my head told me to do it. 😉
*sigh* your comment engine ate my faces-config.xml markup at the beginning. 🙁
The way to create your own FacesContext is something completely different. I didn’t wrote a new FacesContext (which would destroy the XPages functionality). I modified the existing one.
Just think about some limitations: I can’t see a reason why there is a stupid „:“ used in the Client id’s. Or why there is no Annotation for beans implemented. Why not change that?
„I didn’t wrote a new FacesContext (which would destroy the XPages functionality)“
Why would it destroy the XPages functionality? You can extend what’s already there. You don’t have to have to start from scratch.
And yeah, there’s lots of advantages to doing so. You offer good examples.
Because it just not work as shown in the StarterKit. Have a look here: http://hasselba.ch/blog/?p=1414.