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

Reply via email to