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-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
> >
>
