1

I have two bases :

Model A.ntf
Model B.ntf which inherited of A
Base B1.nsf from B

I have a faces-config in A and B, but i'd like change the faces-config of B. I can't do that because when i change it and update design, the faces-config became as it is at first...

So, i'd like use a file in the ressources to include a piece of faces-config by this way.

But what is the code to do that ?

An idea ? or another thinks to do ?

thanks

sissi49
  • 135
  • 1
  • 11

3 Answers3

1

I've been thinking about this one and I do have an idea of how to hack it. Of course I would first and foremost look into the options as described by @stwissel. All what the faces-config.xml file does is make a java instance available to the runtime. You can do this manually in both java and javascript.

javascript

function MyBean{
    this.getInstance = function(){
          return de.company.project.MyBean.getInstance();
    }
    return this;
}

Java

public static getInstance(){
     Map<String, Object> scopeMap = ExtLibUtil.getSessionScope();
        if(!scopeMap.containsKey(BEAN_NAME)){
            scopeMap.put(BEAN_NAME, new MyBean();)
        }
        return scopeMap.get(Bean_Name);
}

you can then access all beans as you want and the ssjs files contain the possibility to not allow design refreshes.

you can also always import this ssjs file into others

import ssjs_MyBean;

Again, hacky, but sometimes there is nothing like a good hack! Please also keep in mind that this would not allow EL (I dont think) It is strictly getting an instance of a class.

Greg
  • 714
  • 4
  • 16
  • 1
    i really doubt it will work with EL. I just cannot understand how it could. With getters() though, you could definitely retrieve lists and other fun stuff that allow you to keep your code in java, and in two different places, allowing for inheritance simply. The trade off would be EL and maybe some other bean specific abilities. You can, however, keep your objects in memory to allow for some scoped caching. – Greg Jul 18 '14 at 12:32
  • Nice one. But the lack of EL support makes it really a hack – stwissel Jul 18 '14 at 12:32
  • quick / dirty / hacky / you cant always have your cake and coffee too. – Greg Jul 18 '14 at 12:34
0

When you inherit the whole database, you can't alter design elements easily. The exposed ones (in the menu) have the "don't allow design update" flag, but AFAIK the flag isn't exposed for faces-config. What you can do: Do not inherit B from A as a whole, but just copy the design elements you need and say YES for the inheritance.

If you have a lot of stuff, you might consider moving design elements to an extension library, so any of your applications can benefit from them.

You also could use a specific build process to copy elements around. There is a build server in the making too.

stwissel
  • 20,110
  • 6
  • 54
  • 101
  • good to know. I was curious if building your own OSGi plug-ins/libraries are the only option. – Greg Jul 18 '14 at 10:17
  • you says "If you have a lot of stuff, you might consider moving design elements to an extension library, so any of your applications can benefit from them.". How do you do that ? please ? – sissi49 Jul 18 '14 at 10:28
  • you create a Library with the java class, isn't it ? but where do you declare the managed beans ?? or i create a factory to instantiate the java class (there aren't managed beans, so , there are only beans) – sissi49 Jul 18 '14 at 10:39
  • The managed beans need to be declared in each nsf. Of course when you build your own library you can design your own global objects. The XPages Extension Library book also explains how to make your own library – stwissel Jul 18 '14 at 12:30
-1

In fact, I add all my managed-bean in the first faces-config. And it's ok. Simple ! It's inherited for all my bases and there is no problem in the base or models which the class are not create if they aren't called ! thanks for all !

sissi49
  • 135
  • 1
  • 11
  • 1
    I am not so certain that is a good idea. If you have a database that only inherits from your first template and does not contain the code that was defined in your second, then you are going to have exceptions if you accidently make use of one of the defined beans that lacks the java class. I guess it is "ok" if you have everything very well documented and commented, but I think you are asking for trouble down the line. – Greg Jul 21 '14 at 12:53