As step 0 of SHALE-263 [1], here [2] is an initial cut of the
stylesheet for producing the needed SCXML documents from Shale dialog
configuration files. That directory [2] also contains the result of
styling the dialog-config.xml that comes with the Shale usecases
application (log on / edit
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
I would like to propose a best practice for the name attribute used in
various bits of the XML vocabulary for Shale dialogs that recommends
restricting these to alphanumeric characters
On 8/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
Ah, missed this in the earlier post about styling, but perhaps it
needs a new thread anyway. That style [1] does not process the
className attribute of all the legal dialog config elements. The
className attribute came in through SHALE-120 [2].
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different. How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the Pay By
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different. How
would this be done with dialog managed
Rahul,
This was not a how to do I do this question. It was in reference to
the current Dialog Manager design effort.
Paul Spencer
Rahul Akolkar wrote:
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
An advantage with the current
I have few initial concerns after looking over the excellent
documentation and examples on the Commons SCXML site.
So far, my concerns are as follows:
1.) I'm not wild about having to run an XSL transform on dialogs
during compile time but the SCXML approach to configuring dialogs
seems to
@Sean - I take it you are using this attribute? Any ideas here? Can
you please explain (again) how you use it? There may be other ways to
achieve the desired results, from an SCXML PoV. Ofcourse, that will
only be applicable for new applications.
Basically there were a bunch of shortcoming in
On 8/25/06, Sean Schofield [EMAIL PROTECTED] wrote:
I have few initial concerns after looking over the excellent
documentation and examples on the Commons SCXML site.
So far, my concerns are as follows:
1.) I'm not wild about having to run an XSL transform on dialogs
during compile time but
I think Paul was commenting on an earlier idea that I had about
scrapping #{dialog.data} in favor of a managed bean type solution. If
I'm reading his message correctly he raises some good points. I think
we're past that idea now though in favor of keeping #{dialog.data} but
no longer blowing
On the wiki[1], we've got mandatory requirement #9 talking about support for
Support for multiple active dialog instances within a single page (i.e.
more than one instance within a particular JSF view. Thinking about this
further, I'm not sure we really need that ... and Seam doesn't support it
On 8/25/06, Sean Schofield [EMAIL PROTECTED] wrote:
I have few initial concerns after looking over the excellent
documentation and examples on the Commons SCXML site.
So far, my concerns are as follows:
1.) I'm not wild about having to run an XSL transform on dialogs
during compile time
snip/
On 8/25/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 8/24/06, Craig McClanahan [EMAIL PROTECTED] wrote:
That would be good. But I also ran into something else post-1.0.3 ...
apparently profiles are not inherited the way I thought they were
either, so
having the JSFRI-versus-MyFaces decision
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Rahul,
I'm trying to set up a quick Shale Sandbox project where we can experiment
with the SCXML integration we've been discussing on the Shale Dev list.
snip/
Cool, should be fun.
I notice that you've released version 0.5, but I don't
14 matches
Mail list logo
