Tahnks Rahul for your explanation. My requirements is: At the moment I have an application that start a dialog with name "D1". A new customer need to change the dialog (for ex."D1_1") because want a specific dialog if a user work in a specific group. So, I don't want change the code of my asset by I want change something outer the application code. At the moment I have a component that read the dialogs.xml in a specific file system out of the war. The only thing to do is change the dialog name basing on user information. The solution I'm using at the moment (does work) is:
I have the following a wrapper to org.apache.shale.dialog.basic.BasicDialogManager: public class BasicDialogManagerWrapper implements DialogContextManager { public static final String WRAPPED_BASIC_DIALOG_CONTEXT_MANAGER= "xx"; private DialogContextManager wrapped; ....... ....... public BasicDialogManagerWrapper() { super(); FacesContext context = FacesContext.getCurrentInstance(); VariableResolver variableResolver = context.getApplication().getVariableResolver(); wrapped = (DialogContextManager)variableResolver. resolveVariable(context, WRAPPED_BASIC_DIALOG_CONTEXT_MANAGER); ..... } public DialogContext create(FacesContext context, String name) { return wrapped. (context, customizableDialogsManager.checkDialog(name)); } public DialogContext create(FacesContext context, String name, DialogContext parent) { return wrapped.create(context, customizableDialogsManager.checkDialog(name),parent); } public DialogContext get(String id) { return wrapped.get(id); } public DialogContext getActiveDialogContext(FacesContext context) { return wrapped.getActiveDialogContext(context); } public void remove(DialogContext instance) { wrapped.remove(instance); } public void addDialogContextManagerListener(DialogContextManagerListener listener) { wrapped.addDialogContextManagerListener(listener); } public DialogContextManagerListener[] getDialogContextManagerListeners() { return wrapped.getDialogContextManagerListeners(); } public void removeDialogContextManagerListener(DialogContextManagerListener listener) { wrapped.removeDialogContextManagerListener(listener); } } This wrapper use an istance of org.apache.shale.dialog.basic.BasicDialogManager created at session scope. This is the faces-config: <managed-bean> <managed-bean-name>org.apache.shale.dialog.MANAGER</managed-bean-name> <managed-bean-class>it.xxx.BasicDialogManagerWrapper</managed-bean-class > <managed-bean-scope>session</managed-bean-scope> </managed-bean> <managed-bean> <managed-bean-name> it.accenture.web.shale.dialog.customizable_dialogs.jsf.WRAPPED_BASIC_DIA LOG_CONTEXT_MANAGER </managed-bean-name> <managed-bean-class> org.apache.shale.dialog.basic.BasicDialogManager </managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean> I know that you can think that the requirement is strange but I would like to know if there is some possible problem using this solution. Thanks in advance Mario -----Original Message----- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: 27 luglio 2007 22.33 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'm sorry Rahul but I don't understand your response (sure is for my bad > English). <snip/> Please feel free to ask me to repeat anything that isn't clear, I will try again. > Can you explain: > " If it must be so (for whatever reason that I am no longer > trying to identify :-), then it must not claim to be any variant of > the basic impl anyway." > <snap/> That was in context of the fact that your requirements seem to necessitate breaking one of the basic contracts of the DialogContextManager interface. One of the reasons why the impls of that interface are final is probably to avoid getting into such situations in the first place. Again, I'd encourage you to work towards getting rid of the requirement of creating a DialogContext of a different name than the one that was supplied. I suspect it is merely symptomatic of some other, perhaps more important, application design problem. -Rahul > Thanks > Mario > This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.