Re: Passing data between a dialog and a subdialog
your Question is illustrated under the following Thread:http://www.nabble.com/transition-between-2-Dialog-tf3885103.html#a11029950 and here is the Solution: Graig wrote: Two ideas for how to do this: * (As I mentioned in the previous response), store a reference to your parent dialog's data object *separately* in session scope so that it can be accessed directly. * Ensure that the subdialog receives the same data object as the parent dialog does. Note that it is not good enough to have the same data *class*, you really need the same *instance* of that class in order to share data. Craig Sam marc.jaeckle wrote: Hi everybody, is there a way to pass data between a dialog and a subdialog in the basic implementation or between a dialog state and a subdialog state of the scxml implementation? I'm looking for something similar to the attribute mappers that Spring Web Flow features. The idea is to treat the dialogs as black boxes that have defined input and output values (I'm not talking about string outcomes but actual business data here) so they can be reused easily in different contexts. Example to illustrate the problem: There is a partsDialog that displays information on car parts. The partsDialog allows the user to open a subdialog to search for a specific part of a car to display information on that part. The partsDialog initializes the searchPart subdialog with the type of the car and the searchPart subdialog returns a part number to the partsDialog when it is done. The searchPart subdialog is also to be used as a subdialog in other contexts. Gruß Marc -- View this message in context: http://www.nabble.com/Passing-data-between-a-dialog-and-a-subdialog-tf4128322.html#a11741044 Sent from the Shale - User mailing list archive at Nabble.com.
AW: Passing data between a dialog and a subdialog
But is there also a way to do that in the xml dialog definition. Something like subflow-state id=searchPart flow=search-part-flow attribute-mapper input-mapper name=someobject.carType as=carType / output-mapping name=partNumber as=someObject.partNumber/ /attribute-mapper ... /subflow-state (Web Flow example) Gruß Marc -Ursprüngliche Nachricht- Von: samju [mailto:[EMAIL PROTECTED] Gesendet: Mo 23.07.2007 12:07 An: user@shale.apache.org Betreff: Re: Passing data between a dialog and a subdialog your Question is illustrated under the following Thread:http://www.nabble.com/transition-between-2-Dialog-tf3885103.html#a11029950 and here is the Solution: Graig wrote: Two ideas for how to do this: * (As I mentioned in the previous response), store a reference to your parent dialog's data object *separately* in session scope so that it can be accessed directly. * Ensure that the subdialog receives the same data object as the parent dialog does. Note that it is not good enough to have the same data *class*, you really need the same *instance* of that class in order to share data. Craig Sam marc.jaeckle wrote: Hi everybody, is there a way to pass data between a dialog and a subdialog in the basic implementation or between a dialog state and a subdialog state of the scxml implementation? I'm looking for something similar to the attribute mappers that Spring Web Flow features. The idea is to treat the dialogs as black boxes that have defined input and output values (I'm not talking about string outcomes but actual business data here) so they can be reused easily in different contexts. Example to illustrate the problem: There is a partsDialog that displays information on car parts. The partsDialog allows the user to open a subdialog to search for a specific part of a car to display information on that part. The partsDialog initializes the searchPart subdialog with the type of the car and the searchPart subdialog returns a part number to the partsDialog when it is done. The searchPart subdialog is also to be used as a subdialog in other contexts. Gruß Marc -- View this message in context: http://www.nabble.com/Passing-data-between-a-dialog-and-a-subdialog-tf4128322.html#a11741044 Sent from the Shale - User mailing list archive at Nabble.com.
Re: Passing data between a dialog and a subdialog
On 7/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But is there also a way to do that in the xml dialog definition. Something like subflow-state id=searchPart flow=search-part-flow attribute-mapper input-mapper name=someobject.carType as=carType / output-mapping name=partNumber as=someObject.partNumber/ /attribute-mapper ... /subflow-state (Web Flow example) snip/ * Basic implementation: No, there isn't a declarative way to do that via the dialog-config.xml. However, feel free to open an enhancement request via JIRA [1] about making data flow easier / more elegant across parent-child dialogs (if there isn't one already, please check existing tickets). * SCXML implementation: Subdialogs receive the same dialog data (same instance of data class) so there is no need for any such elaborate mechanism. -Rahul [1] http://shale.apache.org/issue-tracking.html Gruß Marc -Ursprüngliche Nachricht- Von: samju [mailto:[EMAIL PROTECTED] Gesendet: Mo 23.07.2007 12:07 An: user@shale.apache.org Betreff: Re: Passing data between a dialog and a subdialog your Question is illustrated under the following Thread:http://www.nabble.com/transition-between-2-Dialog-tf3885103.html#a11029950 and here is the Solution: Graig wrote: Two ideas for how to do this: * (As I mentioned in the previous response), store a reference to your parent dialog's data object *separately* in session scope so that it can be accessed directly. * Ensure that the subdialog receives the same data object as the parent dialog does. Note that it is not good enough to have the same data *class*, you really need the same *instance* of that class in order to share data. Craig Sam marc.jaeckle wrote: Hi everybody, is there a way to pass data between a dialog and a subdialog in the basic implementation or between a dialog state and a subdialog state of the scxml implementation? I'm looking for something similar to the attribute mappers that Spring Web Flow features. The idea is to treat the dialogs as black boxes that have defined input and output values (I'm not talking about string outcomes but actual business data here) so they can be reused easily in different contexts. Example to illustrate the problem: There is a partsDialog that displays information on car parts. The partsDialog allows the user to open a subdialog to search for a specific part of a car to display information on that part. The partsDialog initializes the searchPart subdialog with the type of the car and the searchPart subdialog returns a part number to the partsDialog when it is done. The searchPart subdialog is also to be used as a subdialog in other contexts. Gruß Marc
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);
}
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:[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? :)
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:[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?
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: [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?
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: Any sucess with shale nightly 20070717 and RI JSF 1.2?
signature.asc Description: OpenPGP digital signature
