RE: Customizing Basic DialogContextManager
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-nameorg.apache.shale.dialog.MANAGER/managed-bean-name
managed-bean-classit.xxx.BasicDialogManagerWrapper/managed-bean-class
managed-bean-scopesession/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-scopesession/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
Re: Customizing Basic DialogContextManager
On 7/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
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.
snip/
I can understand not wanting to change your asset (presumably for
reusability) but this is application code (rather than framework /
dialog API implementation code), so the asset would be better served
being more flexible.
For example, instead of starting a dialog like so:
h:commandLink action=dialog:D1 /
the asset would start it like so:
h:commandLink action=#{dialogchooser.name('D1')} /
where the name method of the dialogchooser bean uses some
application-configured way of returning the required dialog name
(D1_1), and perhaps the default behavior is identity (i.e. D1 itself
is returned). This keeps application-specific code in the application
layer and keeps the asset reusable as well.
Note that I'm using JBoss EL (parameterized method bindings) for
brevity in the above example as an illustration. Perhaps you may need
f:param or some such technique instead.
Finally, the approach below will probably work (I wouldn't recommend it).
-Rahul
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-nameorg.apache.shale.dialog.MANAGER/managed-bean-name
managed-bean-classit.xxx.BasicDialogManagerWrapper/managed-bean-class
managed-bean-scopesession/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-scopesession/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
