On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi Rahul,
thanks for your answer.
> Subdialogs receive the same dialog data (same instance of data
> class) so there is no need for any such elaborate mechanism.
I find it a bit dangerous to let two independent "components" work on the same
set of data especially if the components are being developed by different people
(potentially in different places). Shouldn't we treat a client component the same way we
would treat a server component? If we do so, the client components should also have well
defined interfaces through which they talk with each other (the interfaces don't have to
be Java interfaces).
<snip/>
The SCXML implementation has its own view about the "independence" of
parent-child dialogs. Subdialogs are white boxes, you can look in, you
can navigate directly to a state therein, you can access the
data(model), you can attach listeners to the parent that watch changes
in a subdialog for behavioral niceties etc. i.e. most things are
transparent. For some set of applications, this works well (without
manufactured interfaces and stunning XML vocabularies).
Just think of a large distributed development team in which every developer is
assigned to work on a different (complex) dialog and the dialogs interact with
each other. Then throw farshoring and dialog reuse across different IT
companies for the same customer into the mix :-)
<snap/>
As you have articulated above, for another set of applications, there
are additional considerations at play. I would like to believe that
the architects who choose the SCXML implementation, choose it for its
extensibility, overall positive impact across the development cycle,
and additional potential exposed by virtue of some of the
transparencies -- and are also aware of what this means it terms of
putting pen to paper (and fingertips to keyboard).
-Rahul
Gruß
Marc
