You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by Rahul Akolkar <ra...@gmail.com> on 2007/07/11 18:20:25 UTC

Re: Customizing Basic DialogContextManager

On 7/10/07, mario.buonopane@accenture.com <ma...@accenture.com> wrote:
> I feel boycotted :)
> May be the problem is my email address?
>
<snip/>

No. Sometimes (or, often, it depends on many factors) it can take a
couple of days to get a response. Please be patient.


> -----Original Message-----
> From: mario.buonopane@accenture.com
> [mailto:mario.buonopane@accenture.com]
> Sent: 9 luglio 2007 11.25
> To: user@shale.apache.org
> Subject: RE: Customizing Basic DialogContextManager
>
> Another way I have tested is to extends directly
> AbstractDialogContextManager overriding all public methods using the
> wrapped
> org.apache.shale.dialog.basic.BasicDialogManager.
>
> Is this solution better then the first?
>
<snap/>

Generally, I'd discourage folks from customizing any of the dialog
impls provided for a couple of reasons (though I'd encourage them to
write brand new impls):

 * Any custom impl means that you are no longer using the basic impl
as we all know it (some bets are off, its harder for anyone on this
list to help without reasonable background each time etc.).

 * It should be possible to get a lot of things done leveraging some
of the features of the dialog framework (such as the various
listeners) before getting into customization. Also, if there are
things missing or value-adds to the dialog framework, then IMO its
better to push for those bits to be included in the API or impls
itself (as the case may be). Perhaps you have done this design
exercise already.

I won't claim to have completely understood what the end goal is for
this particular customization. Is this in any way related to:

 http://issues.apache.org/struts/browse/SHALE-454

that you filed recently?

-Rahul



> Regards
> Mario
>
> P.S. could be easier if org.apache.shale.dialog.basic.BasicDialogManager
> is not final!
>
> -----Original Message-----
> From: mario.buonopane@accenture.com
> [mailto:mario.buonopane@accenture.com]
> Sent: 9 luglio 2007 10.56
> To: user@shale.apache.org
> Subject: Customizing Basic DialogContextManager
>
> Hi, I need to customize the Basic DialogContextManager to just add some
> futures in create method. What I need is create a dialog changing the
> name passed when the user has some profile. What I'm doing is a
> decorator (wrapper) of org.apache.shale.dialog.basic.BasicDialogManager.
> My DialogContextManager (MyDialogContextManager.java ) does not extends
> AbstractDialogContextManager but implements
> org.apache.shale.dialog.DialogContextManager and uses a wrapped object
> of org.apache.shale.dialog.basic.BasicDialogManager :
>
>
>
> public class MyDialogContextManager implements DialogContextManager,
>
>                         Serializable {
>
>
>
>             private static final Log log =
> LogFactory.getLog(MyDialogContextManager.class);
>
>
>
>             DialogContextManager wrapped;
>
>
>
>             public MyDialogContextManager() {
>
>                         super();
>
>                         wrapped = new BasicDialogManager();
>
>
> FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> ut("mypipolo",wrapped);
>
>             }
>
>
>
>             public DialogContext create(FacesContext context, String
> name) {
>
> //this is what I need:
>
>                         If (blablaba....) name="mydialogname";
>
>
>
>                         return wrapped.create(context,name);
>
>             }
>
>
>
>             public DialogContext create(FacesContext context, String
> name, DialogContext parent) {
>
>                         return wrapped.create(context,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);
>
>             }
>
>
>
> }
>
>
>
> In my faces-config I added:
>
>       <managed-bean>
>
>
> <managed-bean-name>org.apache.shale.dialog.MANAGER</managed-bean-name>
>
>
> <managed-bean-class>prova.MyDialogContextManager</managed-bean-class>
>
>             <managed-bean-scope>session</managed-bean-scope>
>
>       </managed-bean>
>
>
>
>
>
> If you analyze the constructor, you find this:
>
>
> FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> ut("mypipolo",wrapped);
>
>
>
> I need this because MyDialogContextManager does not extends
> AbstractDialogContextManager and doing so does not implements
> HttpSessionBindingListener needed for set DialogLifecycleListener.
>
>
>
> So, doing in this way seems to work correctly but the question is:
>
> Is this a correct way to customize the default implementation of
> BasicDialogManager?
>
>
>

Re: Customizing Basic DialogContextManager

Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/31/07, mario.buonopane@accenture.com <ma...@accenture.com> wrote:
> Rahul, thanks for your reply.
> At the moment I have all action calling a managed bean:
>   <h:commandLink action="#{mybean.myaction}" .... />
> And the action return the dialog name.
> Unfortunately the dialog name is not build using a "dialogchooser" and I
> can't use your approach without change the code (I agree should be the
> best way to do).
> The curiosity is: "Why you don't recommend my approach?"
>
<snip/>

Because there is application specific behavior in the dialog
implementation (and dialog implementations should be
application-agnostic). I understand you have other constraints.

-Rahul


> Ciao
> Mario
>

RE: Customizing Basic DialogContextManager

Posted by ma...@accenture.com.
Rahul, thanks for your reply.
At the moment I have all action calling a managed bean:
  <h:commandLink action="#{mybean.myaction}" .... />
And the action return the dialog name.
Unfortunately the dialog name is not build using a "dialogchooser" and I
can't use your approach without change the code (I agree should be the
best way to do).
The curiosity is: "Why you don't recommend my approach?"

Ciao
Mario 



-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: 31 luglio 2007 00.09
To: user@shale.apache.org
Subject: Re: Customizing Basic DialogContextManager

On 7/30/07, mario.buonopane@accenture.com
<ma...@accenture.com> 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:rahul.akolkar@gmail.com]
> Sent: 27 luglio 2007 22.33
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/25/07, mario.buonopane@accenture.com
> <ma...@accenture.com> 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.

Re: Customizing Basic DialogContextManager

Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/30/07, mario.buonopane@accenture.com <ma...@accenture.com> 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:rahul.akolkar@gmail.com]
> Sent: 27 luglio 2007 22.33
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/25/07, mario.buonopane@accenture.com
> <ma...@accenture.com> 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
> >
>

RE: Customizing Basic DialogContextManager

Posted by ma...@accenture.com.
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:rahul.akolkar@gmail.com] 
Sent: 27 luglio 2007 22.33
To: user@shale.apache.org
Subject: Re: Customizing Basic DialogContextManager

On 7/25/07, mario.buonopane@accenture.com
<ma...@accenture.com> 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.

Re: Customizing Basic DialogContextManager

Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/25/07, mario.buonopane@accenture.com <ma...@accenture.com> 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
>

RE: Customizing Basic DialogContextManager

Posted by ma...@accenture.com.
I'm sorry Rahul but I don't understand your response (sure is for my bad
English).
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."

Thanks 
Mario 

-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: 24 luglio 2007 21.12
To: user@shale.apache.org
Subject: Re: Customizing Basic DialogContextManager

On 7/24/07, mario.buonopane@accenture.com
<ma...@accenture.com> wrote:
> The reason is that I have, in special cases, to change the name of the
> dialog name to start and I can't change the code of my web
application.
<snip/>

I'd say make sure you have the right name before you hit the basic
dialog manager impl (but you already seem to indicate thats not
possible).


> For example:
> public ... create(javax.faces.context.FacesContext context,
>                    String name)
>  {
>         if(usaPresident.equalsIgnoreCase("BUSH")) name =
"NoWarsPlease";
>
>       super.create(context,name);
> }
>
> (I don't understand the antipattern.....
> and I don't understand why
> org.apache.shale.dialog.basic.BasicDialogManager is final)
>
<snap/>

Its along these lines:

 * Shale has one dialog API and many potential dialog implementations
 * Each implementation defines certain contracts (these must adhere to
the contracts in the API, and may additionally define impl-specific
contracts and features as well)
 * If subclassing is allowed, it may be possible that the subclass
(knowingly or unknowingly) ceases to honor some of the contracts for
that impl
 * As an aside, the mechanics of getting subclassing to work as
expected are cumbersome (since that wasn't a design consideration)

Lets look at your example above:

The dialog manager contract indicates that the create() method will
instantiate a dialog context for the given dialog name. By returning a
dialog context for another dialog name, that contract is no longer
fulfilled. 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.

-Rahul


> Thanks
> Mario
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: 23 luglio 2007 21.19
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/20/07, mario.buonopane@accenture.com
> <ma...@accenture.com> wrote:
> > Hi Rahul,
> > What I need is to extend the "create" method of
> > org.apache.shale.dialog.basic.BasicDialogManager
> >
> > for example doing:
> >
> > public ... create(javax.faces.context.FacesContext context,
> >                   String name)
> > {
> >         Super.create(context,name);
> >       System.out.println("Hello Rahul");
> > }
> >
> <snip/>
>
> I'm saying this is more an anti-pattern (i.e. avoid, if possible :-)
>
> Can you use the DialogContextManagerListener [1] for this purpose? If
> not, I'll go back to my questions two replies ago -- what is the
> reason? Is the reason related to SHALE-454 [2] ?
>
> -Rahul
>
> [1]
>
http://shale.apache.org/shale-dialog/apidocs/org/apache/shale/dialog/Dia
> logContextManagerListener.html
>
> [2] http://issues.apache.org/struts/browse/SHALE-454
>
>
>
> >
> > 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.

Re: Customizing Basic DialogContextManager

Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/24/07, mario.buonopane@accenture.com <ma...@accenture.com> wrote:
> The reason is that I have, in special cases, to change the name of the
> dialog name to start and I can't change the code of my web application.
<snip/>

I'd say make sure you have the right name before you hit the basic
dialog manager impl (but you already seem to indicate thats not
possible).


> For example:
> public ... create(javax.faces.context.FacesContext context,
>                    String name)
>  {
>         if(usaPresident.equalsIgnoreCase("BUSH")) name = "NoWarsPlease";
>
>       super.create(context,name);
> }
>
> (I don't understand the antipattern.....
> and I don't understand why
> org.apache.shale.dialog.basic.BasicDialogManager is final)
>
<snap/>

Its along these lines:

 * Shale has one dialog API and many potential dialog implementations
 * Each implementation defines certain contracts (these must adhere to
the contracts in the API, and may additionally define impl-specific
contracts and features as well)
 * If subclassing is allowed, it may be possible that the subclass
(knowingly or unknowingly) ceases to honor some of the contracts for
that impl
 * As an aside, the mechanics of getting subclassing to work as
expected are cumbersome (since that wasn't a design consideration)

Lets look at your example above:

The dialog manager contract indicates that the create() method will
instantiate a dialog context for the given dialog name. By returning a
dialog context for another dialog name, that contract is no longer
fulfilled. 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.

-Rahul


> Thanks
> Mario
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: 23 luglio 2007 21.19
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/20/07, mario.buonopane@accenture.com
> <ma...@accenture.com> wrote:
> > Hi Rahul,
> > What I need is to extend the "create" method of
> > org.apache.shale.dialog.basic.BasicDialogManager
> >
> > for example doing:
> >
> > public ... create(javax.faces.context.FacesContext context,
> >                   String name)
> > {
> >         Super.create(context,name);
> >       System.out.println("Hello Rahul");
> > }
> >
> <snip/>
>
> I'm saying this is more an anti-pattern (i.e. avoid, if possible :-)
>
> Can you use the DialogContextManagerListener [1] for this purpose? If
> not, I'll go back to my questions two replies ago -- what is the
> reason? Is the reason related to SHALE-454 [2] ?
>
> -Rahul
>
> [1]
> http://shale.apache.org/shale-dialog/apidocs/org/apache/shale/dialog/Dia
> logContextManagerListener.html
>
> [2] http://issues.apache.org/struts/browse/SHALE-454
>
>
>
> >
> > Thanks
> > Mario
> >

RE: Customizing Basic DialogContextManager

Posted by ma...@accenture.com.
The reason is that I have, in special cases, to change the name of the
dialog name to start and I can't change the code of my web application.
For example:
public ... create(javax.faces.context.FacesContext context,
                   String name)
 {
	if(usaPresident.equalsIgnoreCase("BUSH")) name = "NoWarsPlease";

      super.create(context,name);
}

(I don't understand the antipattern.....
and I don't understand why
org.apache.shale.dialog.basic.BasicDialogManager is final)

Thanks
Mario 
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: 23 luglio 2007 21.19
To: user@shale.apache.org
Subject: Re: Customizing Basic DialogContextManager

On 7/20/07, mario.buonopane@accenture.com
<ma...@accenture.com> wrote:
> Hi Rahul,
> What I need is to extend the "create" method of
> org.apache.shale.dialog.basic.BasicDialogManager
>
> for example doing:
>
> public ... create(javax.faces.context.FacesContext context,
>                   String name)
> {
>         Super.create(context,name);
>       System.out.println("Hello Rahul");
> }
>
<snip/>

I'm saying this is more an anti-pattern (i.e. avoid, if possible :-)

Can you use the DialogContextManagerListener [1] for this purpose? If
not, I'll go back to my questions two replies ago -- what is the
reason? Is the reason related to SHALE-454 [2] ?

-Rahul

[1]
http://shale.apache.org/shale-dialog/apidocs/org/apache/shale/dialog/Dia
logContextManagerListener.html

[2] http://issues.apache.org/struts/browse/SHALE-454



>
> Thanks
> Mario
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: 19 luglio 2007 22.37
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/17/07, mario.buonopane@accenture.com
> <ma...@accenture.com> wrote:
> > No response? Every body to the beach? :)
> >
> <snip/>
>
> For me to say anything else here, I'd need a bit more about what you
> are trying to do (rather than the how, which you've detailed below)
> and what the basic implementation is hindering you from doing.
>
> -Rahul
>
>
>
> > Ciao
> > Mario
> >
> > -----Original Message-----
> > From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> > Sent: 11 luglio 2007 18.20
> > To: user@shale.apache.org
> > Subject: Re: Customizing Basic DialogContextManager
> >
> > On 7/10/07, mario.buonopane@accenture.com
> > <ma...@accenture.com> wrote:
> > > I feel boycotted :)
> > > May be the problem is my email address?
> > >
> > <snip/>
> >
> > No. Sometimes (or, often, it depends on many factors) it can take a
> > couple of days to get a response. Please be patient.
> >
> >
> > > -----Original Message-----
> > > From: mario.buonopane@accenture.com
> > > [mailto:mario.buonopane@accenture.com]
> > > Sent: 9 luglio 2007 11.25
> > > To: user@shale.apache.org
> > > Subject: RE: Customizing Basic DialogContextManager
> > >
> > > Another way I have tested is to extends directly
> > > AbstractDialogContextManager overriding all public methods using
the
> > > wrapped
> > > org.apache.shale.dialog.basic.BasicDialogManager.
> > >
> > > Is this solution better then the first?
> > >
> > <snap/>
> >
> > Generally, I'd discourage folks from customizing any of the dialog
> > impls provided for a couple of reasons (though I'd encourage them to
> > write brand new impls):
> >
> >  * Any custom impl means that you are no longer using the basic impl
> > as we all know it (some bets are off, its harder for anyone on this
> > list to help without reasonable background each time etc.).
> >
> >  * It should be possible to get a lot of things done leveraging some
> > of the features of the dialog framework (such as the various
> > listeners) before getting into customization. Also, if there are
> > things missing or value-adds to the dialog framework, then IMO its
> > better to push for those bits to be included in the API or impls
> > itself (as the case may be). Perhaps you have done this design
> > exercise already.
> >
> > I won't claim to have completely understood what the end goal is for
> > this particular customization. Is this in any way related to:
> >
> >  http://issues.apache.org/struts/browse/SHALE-454
> >
> > that you filed recently?
> >
> > -Rahul
> >
> >
> >
> > > Regards
> > > Mario
> > >
> > > P.S. could be easier if
> > org.apache.shale.dialog.basic.BasicDialogManager
> > > is not final!
> > >
<snap/>


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.

Re: Customizing Basic DialogContextManager

Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/20/07, mario.buonopane@accenture.com <ma...@accenture.com> wrote:
> Hi Rahul,
> What I need is to extend the "create" method of
> org.apache.shale.dialog.basic.BasicDialogManager
>
> for example doing:
>
> public ... create(javax.faces.context.FacesContext context,
>                   String name)
> {
>         Super.create(context,name);
>       System.out.println("Hello Rahul");
> }
>
<snip/>

I'm saying this is more an anti-pattern (i.e. avoid, if possible :-)

Can you use the DialogContextManagerListener [1] for this purpose? If
not, I'll go back to my questions two replies ago -- what is the
reason? Is the reason related to SHALE-454 [2] ?

-Rahul

[1] http://shale.apache.org/shale-dialog/apidocs/org/apache/shale/dialog/DialogContextManagerListener.html

[2] http://issues.apache.org/struts/browse/SHALE-454



>
> Thanks
> Mario
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: 19 luglio 2007 22.37
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/17/07, mario.buonopane@accenture.com
> <ma...@accenture.com> wrote:
> > No response? Every body to the beach? :)
> >
> <snip/>
>
> For me to say anything else here, I'd need a bit more about what you
> are trying to do (rather than the how, which you've detailed below)
> and what the basic implementation is hindering you from doing.
>
> -Rahul
>
>
>
> > Ciao
> > Mario
> >
> > -----Original Message-----
> > From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> > Sent: 11 luglio 2007 18.20
> > To: user@shale.apache.org
> > Subject: Re: Customizing Basic DialogContextManager
> >
> > On 7/10/07, mario.buonopane@accenture.com
> > <ma...@accenture.com> wrote:
> > > I feel boycotted :)
> > > May be the problem is my email address?
> > >
> > <snip/>
> >
> > No. Sometimes (or, often, it depends on many factors) it can take a
> > couple of days to get a response. Please be patient.
> >
> >
> > > -----Original Message-----
> > > From: mario.buonopane@accenture.com
> > > [mailto:mario.buonopane@accenture.com]
> > > Sent: 9 luglio 2007 11.25
> > > To: user@shale.apache.org
> > > Subject: RE: Customizing Basic DialogContextManager
> > >
> > > Another way I have tested is to extends directly
> > > AbstractDialogContextManager overriding all public methods using the
> > > wrapped
> > > org.apache.shale.dialog.basic.BasicDialogManager.
> > >
> > > Is this solution better then the first?
> > >
> > <snap/>
> >
> > Generally, I'd discourage folks from customizing any of the dialog
> > impls provided for a couple of reasons (though I'd encourage them to
> > write brand new impls):
> >
> >  * Any custom impl means that you are no longer using the basic impl
> > as we all know it (some bets are off, its harder for anyone on this
> > list to help without reasonable background each time etc.).
> >
> >  * It should be possible to get a lot of things done leveraging some
> > of the features of the dialog framework (such as the various
> > listeners) before getting into customization. Also, if there are
> > things missing or value-adds to the dialog framework, then IMO its
> > better to push for those bits to be included in the API or impls
> > itself (as the case may be). Perhaps you have done this design
> > exercise already.
> >
> > I won't claim to have completely understood what the end goal is for
> > this particular customization. Is this in any way related to:
> >
> >  http://issues.apache.org/struts/browse/SHALE-454
> >
> > that you filed recently?
> >
> > -Rahul
> >
> >
> >
> > > Regards
> > > Mario
> > >
> > > P.S. could be easier if
> > org.apache.shale.dialog.basic.BasicDialogManager
> > > is not final!
> > >
<snap/>

RE: Customizing Basic DialogContextManager

Posted by ma...@accenture.com.
Hi Rahul,
What I need is to extend the "create" method of
org.apache.shale.dialog.basic.BasicDialogManager

for example doing:

public ... create(javax.faces.context.FacesContext context,
                  String name) 
{
	Super.create(context,name);
      System.out.println("Hello Rahul");
}


Thanks
Mario 

-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: 19 luglio 2007 22.37
To: user@shale.apache.org
Subject: Re: Customizing Basic DialogContextManager

On 7/17/07, mario.buonopane@accenture.com
<ma...@accenture.com> wrote:
> No response? Every body to the beach? :)
>
<snip/>

For me to say anything else here, I'd need a bit more about what you
are trying to do (rather than the how, which you've detailed below)
and what the basic implementation is hindering you from doing.

-Rahul



> Ciao
> Mario
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: 11 luglio 2007 18.20
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/10/07, mario.buonopane@accenture.com
> <ma...@accenture.com> wrote:
> > I feel boycotted :)
> > May be the problem is my email address?
> >
> <snip/>
>
> No. Sometimes (or, often, it depends on many factors) it can take a
> couple of days to get a response. Please be patient.
>
>
> > -----Original Message-----
> > From: mario.buonopane@accenture.com
> > [mailto:mario.buonopane@accenture.com]
> > Sent: 9 luglio 2007 11.25
> > To: user@shale.apache.org
> > Subject: RE: Customizing Basic DialogContextManager
> >
> > Another way I have tested is to extends directly
> > AbstractDialogContextManager overriding all public methods using the
> > wrapped
> > org.apache.shale.dialog.basic.BasicDialogManager.
> >
> > Is this solution better then the first?
> >
> <snap/>
>
> Generally, I'd discourage folks from customizing any of the dialog
> impls provided for a couple of reasons (though I'd encourage them to
> write brand new impls):
>
>  * Any custom impl means that you are no longer using the basic impl
> as we all know it (some bets are off, its harder for anyone on this
> list to help without reasonable background each time etc.).
>
>  * It should be possible to get a lot of things done leveraging some
> of the features of the dialog framework (such as the various
> listeners) before getting into customization. Also, if there are
> things missing or value-adds to the dialog framework, then IMO its
> better to push for those bits to be included in the API or impls
> itself (as the case may be). Perhaps you have done this design
> exercise already.
>
> I won't claim to have completely understood what the end goal is for
> this particular customization. Is this in any way related to:
>
>  http://issues.apache.org/struts/browse/SHALE-454
>
> that you filed recently?
>
> -Rahul
>
>
>
> > Regards
> > Mario
> >
> > P.S. could be easier if
> org.apache.shale.dialog.basic.BasicDialogManager
> > is not final!
> >
> > -----Original Message-----
> > From: mario.buonopane@accenture.com
> > [mailto:mario.buonopane@accenture.com]
> > Sent: 9 luglio 2007 10.56
> > To: user@shale.apache.org
> > Subject: Customizing Basic DialogContextManager
> >
> > Hi, I need to customize the Basic DialogContextManager to just add
> some
> > futures in create method. What I need is create a dialog changing
the
> > name passed when the user has some profile. What I'm doing is a
> > decorator (wrapper) of
> org.apache.shale.dialog.basic.BasicDialogManager.
> > My DialogContextManager (MyDialogContextManager.java ) does not
> extends
> > AbstractDialogContextManager but implements
> > org.apache.shale.dialog.DialogContextManager and uses a wrapped
object
> > of org.apache.shale.dialog.basic.BasicDialogManager :
> >
> >
> >
> > public class MyDialogContextManager implements DialogContextManager,
> >
> >                         Serializable {
> >
> >
> >
> >             private static final Log log =
> > LogFactory.getLog(MyDialogContextManager.class);
> >
> >
> >
> >             DialogContextManager wrapped;
> >
> >
> >
> >             public MyDialogContextManager() {
> >
> >                         super();
> >
> >                         wrapped = new BasicDialogManager();
> >
> >
> >
>
FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> > ut("mypipolo",wrapped);
> >
> >             }
> >
> >
> >
> >             public DialogContext create(FacesContext context, String
> > name) {
> >
> > //this is what I need:
> >
> >                         If (blablaba....) name="mydialogname";
> >
> >
> >
> >                         return wrapped.create(context,name);
> >
> >             }
> >
> >
> >
> >             public DialogContext create(FacesContext context, String
> > name, DialogContext parent) {
> >
> >                         return wrapped.create(context,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);
> >
> >             }
> >
> >
> >
> > }
> >
> >
> >
> > In my faces-config I added:
> >
> >       <managed-bean>
> >
> >
> >
<managed-bean-name>org.apache.shale.dialog.MANAGER</managed-bean-name>
> >
> >
> >
<managed-bean-class>prova.MyDialogContextManager</managed-bean-class>
> >
> >             <managed-bean-scope>session</managed-bean-scope>
> >
> >       </managed-bean>
> >
> >
> >
> >
> >
> > If you analyze the constructor, you find this:
> >
> >
> >
>
FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> > ut("mypipolo",wrapped);
> >
> >
> >
> > I need this because MyDialogContextManager does not extends
> > AbstractDialogContextManager and doing so does not implements
> > HttpSessionBindingListener needed for set DialogLifecycleListener.
> >
> >
> >
> > So, doing in this way seems to work correctly but the question is:
> >
> > Is this a correct way to customize the default implementation of
> > BasicDialogManager?
> >
> >
> >


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.

Re: Customizing Basic DialogContextManager

Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/17/07, mario.buonopane@accenture.com <ma...@accenture.com> wrote:
> No response? Every body to the beach? :)
>
<snip/>

For me to say anything else here, I'd need a bit more about what you
are trying to do (rather than the how, which you've detailed below)
and what the basic implementation is hindering you from doing.

-Rahul



> Ciao
> Mario
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: 11 luglio 2007 18.20
> To: user@shale.apache.org
> Subject: Re: Customizing Basic DialogContextManager
>
> On 7/10/07, mario.buonopane@accenture.com
> <ma...@accenture.com> wrote:
> > I feel boycotted :)
> > May be the problem is my email address?
> >
> <snip/>
>
> No. Sometimes (or, often, it depends on many factors) it can take a
> couple of days to get a response. Please be patient.
>
>
> > -----Original Message-----
> > From: mario.buonopane@accenture.com
> > [mailto:mario.buonopane@accenture.com]
> > Sent: 9 luglio 2007 11.25
> > To: user@shale.apache.org
> > Subject: RE: Customizing Basic DialogContextManager
> >
> > Another way I have tested is to extends directly
> > AbstractDialogContextManager overriding all public methods using the
> > wrapped
> > org.apache.shale.dialog.basic.BasicDialogManager.
> >
> > Is this solution better then the first?
> >
> <snap/>
>
> Generally, I'd discourage folks from customizing any of the dialog
> impls provided for a couple of reasons (though I'd encourage them to
> write brand new impls):
>
>  * Any custom impl means that you are no longer using the basic impl
> as we all know it (some bets are off, its harder for anyone on this
> list to help without reasonable background each time etc.).
>
>  * It should be possible to get a lot of things done leveraging some
> of the features of the dialog framework (such as the various
> listeners) before getting into customization. Also, if there are
> things missing or value-adds to the dialog framework, then IMO its
> better to push for those bits to be included in the API or impls
> itself (as the case may be). Perhaps you have done this design
> exercise already.
>
> I won't claim to have completely understood what the end goal is for
> this particular customization. Is this in any way related to:
>
>  http://issues.apache.org/struts/browse/SHALE-454
>
> that you filed recently?
>
> -Rahul
>
>
>
> > Regards
> > Mario
> >
> > P.S. could be easier if
> org.apache.shale.dialog.basic.BasicDialogManager
> > is not final!
> >
> > -----Original Message-----
> > From: mario.buonopane@accenture.com
> > [mailto:mario.buonopane@accenture.com]
> > Sent: 9 luglio 2007 10.56
> > To: user@shale.apache.org
> > Subject: Customizing Basic DialogContextManager
> >
> > Hi, I need to customize the Basic DialogContextManager to just add
> some
> > futures in create method. What I need is create a dialog changing the
> > name passed when the user has some profile. What I'm doing is a
> > decorator (wrapper) of
> org.apache.shale.dialog.basic.BasicDialogManager.
> > My DialogContextManager (MyDialogContextManager.java ) does not
> extends
> > AbstractDialogContextManager but implements
> > org.apache.shale.dialog.DialogContextManager and uses a wrapped object
> > of org.apache.shale.dialog.basic.BasicDialogManager :
> >
> >
> >
> > public class MyDialogContextManager implements DialogContextManager,
> >
> >                         Serializable {
> >
> >
> >
> >             private static final Log log =
> > LogFactory.getLog(MyDialogContextManager.class);
> >
> >
> >
> >             DialogContextManager wrapped;
> >
> >
> >
> >             public MyDialogContextManager() {
> >
> >                         super();
> >
> >                         wrapped = new BasicDialogManager();
> >
> >
> >
> FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> > ut("mypipolo",wrapped);
> >
> >             }
> >
> >
> >
> >             public DialogContext create(FacesContext context, String
> > name) {
> >
> > //this is what I need:
> >
> >                         If (blablaba....) name="mydialogname";
> >
> >
> >
> >                         return wrapped.create(context,name);
> >
> >             }
> >
> >
> >
> >             public DialogContext create(FacesContext context, String
> > name, DialogContext parent) {
> >
> >                         return wrapped.create(context,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);
> >
> >             }
> >
> >
> >
> > }
> >
> >
> >
> > In my faces-config I added:
> >
> >       <managed-bean>
> >
> >
> > <managed-bean-name>org.apache.shale.dialog.MANAGER</managed-bean-name>
> >
> >
> > <managed-bean-class>prova.MyDialogContextManager</managed-bean-class>
> >
> >             <managed-bean-scope>session</managed-bean-scope>
> >
> >       </managed-bean>
> >
> >
> >
> >
> >
> > If you analyze the constructor, you find this:
> >
> >
> >
> FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> > ut("mypipolo",wrapped);
> >
> >
> >
> > I need this because MyDialogContextManager does not extends
> > AbstractDialogContextManager and doing so does not implements
> > HttpSessionBindingListener needed for set DialogLifecycleListener.
> >
> >
> >
> > So, doing in this way seems to work correctly but the question is:
> >
> > Is this a correct way to customize the default implementation of
> > BasicDialogManager?
> >
> >
> >

RE: Customizing Basic DialogContextManager

Posted by ma...@accenture.com.
No response? Every body to the beach? :)

Ciao
Mario 

-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: 11 luglio 2007 18.20
To: user@shale.apache.org
Subject: Re: Customizing Basic DialogContextManager

On 7/10/07, mario.buonopane@accenture.com
<ma...@accenture.com> wrote:
> I feel boycotted :)
> May be the problem is my email address?
>
<snip/>

No. Sometimes (or, often, it depends on many factors) it can take a
couple of days to get a response. Please be patient.


> -----Original Message-----
> From: mario.buonopane@accenture.com
> [mailto:mario.buonopane@accenture.com]
> Sent: 9 luglio 2007 11.25
> To: user@shale.apache.org
> Subject: RE: Customizing Basic DialogContextManager
>
> Another way I have tested is to extends directly
> AbstractDialogContextManager overriding all public methods using the
> wrapped
> org.apache.shale.dialog.basic.BasicDialogManager.
>
> Is this solution better then the first?
>
<snap/>

Generally, I'd discourage folks from customizing any of the dialog
impls provided for a couple of reasons (though I'd encourage them to
write brand new impls):

 * Any custom impl means that you are no longer using the basic impl
as we all know it (some bets are off, its harder for anyone on this
list to help without reasonable background each time etc.).

 * It should be possible to get a lot of things done leveraging some
of the features of the dialog framework (such as the various
listeners) before getting into customization. Also, if there are
things missing or value-adds to the dialog framework, then IMO its
better to push for those bits to be included in the API or impls
itself (as the case may be). Perhaps you have done this design
exercise already.

I won't claim to have completely understood what the end goal is for
this particular customization. Is this in any way related to:

 http://issues.apache.org/struts/browse/SHALE-454

that you filed recently?

-Rahul



> Regards
> Mario
>
> P.S. could be easier if
org.apache.shale.dialog.basic.BasicDialogManager
> is not final!
>
> -----Original Message-----
> From: mario.buonopane@accenture.com
> [mailto:mario.buonopane@accenture.com]
> Sent: 9 luglio 2007 10.56
> To: user@shale.apache.org
> Subject: Customizing Basic DialogContextManager
>
> Hi, I need to customize the Basic DialogContextManager to just add
some
> futures in create method. What I need is create a dialog changing the
> name passed when the user has some profile. What I'm doing is a
> decorator (wrapper) of
org.apache.shale.dialog.basic.BasicDialogManager.
> My DialogContextManager (MyDialogContextManager.java ) does not
extends
> AbstractDialogContextManager but implements
> org.apache.shale.dialog.DialogContextManager and uses a wrapped object
> of org.apache.shale.dialog.basic.BasicDialogManager :
>
>
>
> public class MyDialogContextManager implements DialogContextManager,
>
>                         Serializable {
>
>
>
>             private static final Log log =
> LogFactory.getLog(MyDialogContextManager.class);
>
>
>
>             DialogContextManager wrapped;
>
>
>
>             public MyDialogContextManager() {
>
>                         super();
>
>                         wrapped = new BasicDialogManager();
>
>
>
FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> ut("mypipolo",wrapped);
>
>             }
>
>
>
>             public DialogContext create(FacesContext context, String
> name) {
>
> //this is what I need:
>
>                         If (blablaba....) name="mydialogname";
>
>
>
>                         return wrapped.create(context,name);
>
>             }
>
>
>
>             public DialogContext create(FacesContext context, String
> name, DialogContext parent) {
>
>                         return wrapped.create(context,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);
>
>             }
>
>
>
> }
>
>
>
> In my faces-config I added:
>
>       <managed-bean>
>
>
> <managed-bean-name>org.apache.shale.dialog.MANAGER</managed-bean-name>
>
>
> <managed-bean-class>prova.MyDialogContextManager</managed-bean-class>
>
>             <managed-bean-scope>session</managed-bean-scope>
>
>       </managed-bean>
>
>
>
>
>
> If you analyze the constructor, you find this:
>
>
>
FacesContext.getCurrentInstance().getExternalContext().getSessionMap().p
> ut("mypipolo",wrapped);
>
>
>
> I need this because MyDialogContextManager does not extends
> AbstractDialogContextManager and doing so does not implements
> HttpSessionBindingListener needed for set DialogLifecycleListener.
>
>
>
> So, doing in this way seems to work correctly but the question is:
>
> Is this a correct way to customize the default implementation of
> BasicDialogManager?
>
>
>


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.