On 8/23/06, David Geary [EMAIL PROTECTED] wrote:
Would anyone like to review material on Shale dialogs from the upcoming
2nd
ed of Core JSF (about 15 pages)? I have an example with a Bill Pay dialog
that has a Wire Transfer subdialog. The data entered into the subdialog is
incorporated into the
On 8/23/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm not quite convinced that subdialog is very useful as
implemented. I see the usefulness in stringing existing dialogs
together but certain byproducts of subdialog are undesirable. For
instance, SHALE-153 which complains about how you
Hi
I agree with this. I would like to look at subdialogs as a sort of component,
much like we create a Clay component and reuse it in various pages/views. If we
think of subdialogs in this way, we should be able to configure the
state/context going in and where to add state/context going out.
When's the book supposed to be published?
For those who are anxious to learn JSF and can't wait for the 2nd
edition, I suggest you get the first edition now! I wish I had it way
back when I was first trying to understand JSF. I'm happy to review
the whole book if you need a reviewer.
Sean
On
From: Sean Schofield [EMAIL PROTECTED]
No I'm not proposing we deal with generating HTML rendering business
as far as dialogs are concerned. [I'll post a more detailed
explanation on the shale dev list where that belongs.]
This might not be a bad idea. The struts synchronization token
On 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote:
I agree that, if we keep the concept of subdialogs around, mechanisms
for
dealing with this are important. From the perspective of a subdialog, you
should be able to pull data out of the parent dialog's context
transparently
On 8/24/06, Craig McClanahan [EMAIL PROTECTED] wrote:
snip/
In my ideal world scenario, we'll be able to rebuild things on the inside,
with minimal-to-none impact on how an application developer uses it.
However, I'm not convinced that goal is actually achievable, if we're going
to have a
I'd like Shale to support both the current dialog notation and SCXML
as stated here [1], and both can use the same underlying engine. The
current dialog notation by virtue of being the incumbent, and SCXML
because:
* SCXML is a well-defined distillation of all variants of state
machine theory.
On 8/24/06, David Geary [EMAIL PROTECTED] wrote:
Would anyone like to review material on Shale dialogs from the upcoming 2nd
ed of Core JSF (about 15 pages)? I have an example with a Bill Pay dialog
that has a Wire Transfer subdialog. The data entered into the subdialog is
incorporated into the
On 8/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
[snip]
Which brings us to the discussion about sharing dialog data as-in
SHALE-153, and this is where Shale subdialogs deviate from most
dialects of state chart theory, where submachine states are not
processed according to the stack-based
10 matches
Mail list logo
