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? Regards Mario P.S. could be easier if org.apache.shale.dialog.basic.BasicDialogManager is not final! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: org.apache.shale.dialog.MANAGER prova.MyDialogContextManager session 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? Regards Mario Buonopane Accenture Insurance Services & Systems Via C. Colombo 112, 00147 Roma Tel: +39 06 51566543 Mobile: +39 334 6563433 Fax: +39 06 51566550 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. 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
I feel boycotted :) May be the problem is my email address? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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? Regards Mario P.S. could be easier if org.apache.shale.dialog.basic.BasicDialogManager is not final! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: org.apache.shale.dialog.MANAGER prova.MyDialogContextManager session 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? Regards Mario Buonopane Accenture Insurance Services & Systems Via C. Colombo 112, 00147 Roma Tel: +39 06 51566543 Mobile: +39 334 6563433 Fax: +39 06 51566550 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. 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. 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
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I feel boycotted :) May be the problem is my email address? 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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? 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: org.apache.shale.dialog.MANAGER prova.MyDialogContextManager session 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
No response? Every body to the beach? :) Ciao Mario -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: 11 luglio 2007 18.20 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I feel boycotted :) > May be the problem is my email address? > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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? > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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.getDialogContextMa
Re: Customizing Basic DialogContextManager
On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: No response? Every body to the beach? :) 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:[EMAIL PROTECTED] Sent: 11 luglio 2007 18.20 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I feel boycotted :) > May be the problem is my email address? > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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? > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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 > addDialogContextManagerList
RE: Customizing Basic DialogContextManager
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:[EMAIL PROTECTED] Sent: 19 luglio 2007 22.37 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > No response? Every body to the beach? :) > 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:[EMAIL PROTECTED] > Sent: 11 luglio 2007 18.20 > To: user@shale.apache.org > Subject: Re: Customizing Basic DialogContextManager > > On 7/10/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > I feel boycotted :) > > May be the problem is my email address? > > > > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > 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? > > > > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > 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 c
Re: Customizing Basic DialogContextManager
On 7/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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"); } 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:[EMAIL PROTECTED] Sent: 19 luglio 2007 22.37 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > No response? Every body to the beach? :) > 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:[EMAIL PROTECTED] > Sent: 11 luglio 2007 18.20 > To: user@shale.apache.org > Subject: Re: Customizing Basic DialogContextManager > > On 7/10/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > I feel boycotted :) > > May be the problem is my email address? > > > > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > 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? > > > > > 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! > >
RE: Customizing Basic DialogContextManager
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:[EMAIL PROTECTED] Sent: 23 luglio 2007 21.19 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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"); > } > 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:[EMAIL PROTECTED] > Sent: 19 luglio 2007 22.37 > To: user@shale.apache.org > Subject: Re: Customizing Basic DialogContextManager > > On 7/17/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > No response? Every body to the beach? :) > > > > > 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:[EMAIL PROTECTED] > > Sent: 11 luglio 2007 18.20 > > To: user@shale.apache.org > > Subject: Re: Customizing Basic DialogContextManager > > > > On 7/10/07, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > > > I feel boycotted :) > > > May be the problem is my email address? > > > > > > > > > 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: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > > 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? > > > > > > > > > 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! > > > 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
On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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. 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) 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:[EMAIL PROTECTED] Sent: 23 luglio 2007 21.19 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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"); > } > 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
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:[EMAIL PROTECTED] Sent: 24 luglio 2007 21.12 To: user@shale.apache.org Subject: Re: Customizing Basic DialogContextManager On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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. 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) > 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:[EMAIL PROTECTED] > Sent: 23 luglio 2007 21.19 > To: user@shale.apache.org > Subject: Re: Customizing Basic DialogContextManager > > On 7/20/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> 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"); > > } > > > > > 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
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). 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." > 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
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: org.apache.shale.dialog.MANAGER it.xxx.BasicDialogManagerWrapper session it.accenture.web.shale.dialog.customizable_dialogs.jsf.WRAPPED_BASIC_DIA LOG_CONTEXT_MANAGER org.apache.shale.dialog.basic.BasicDialogManager session 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). 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." > 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
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. 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: the asset would start it like so: 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 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: > > > > org.apache.shale.dialog.MANAGER > > it.xxx.BasicDialogManagerWrapper > > session > > > > > it.accenture.web.shale.dialog.customizable_dialogs.jsf.WRAPPED_BASIC_DIA > LOG_CONTEXT_MANAGER > > > org.apache.shale.dialog.basic.BasicDialogManager > > session > > > > 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
RE: Customizing Basic DialogContextManager
Rahul, thanks for your reply. At the moment I have all action calling a managed bean: 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:[EMAIL PROTECTED] Sent: 31 luglio 2007 00.09 To: user@shale.apache.org Subject: 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. 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: the asset would start it like so: 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 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: > > > > org.apache.shale.dialog.MANAGER > > it.xxx.BasicDialogManagerWrapper > > session > > > > > it.accenture.web.shale.dialog.customizable_dialogs.jsf.WRAPPED_BASIC_DIA > LOG_CONTEXT_MANAGER >
Re: Customizing Basic DialogContextManager
On 7/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Rahul, thanks for your reply. > At the moment I have all action calling a managed bean: > > 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?" > 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 >