On 9/6/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
On 9/3/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > Two things -- first, how recent are the bits you're using? I've been making > *lots* of changes through yesterday (a fun way to spend the commercials > while Oregon was whomping on Stanford :-), and the legacy implementation now > works for me. I've also checked in a test app (shale-test-dialog2-legacy) > into the sandbox. This webapp can be used manually to experiment (it even > has a split-screen mode so you can play with two active dialogs in two > different frames), plus it's got a basic system integration test (mvn > -Pitest clean install) to run a couple of simple scenarios automatically. > Next I'll see about doing something similar for the SCXML implementation. > <snip/> The dialog2-scxml bits are probably just at compiles-clean stage. A matching shale-test-dialog2-scxml sibling sounds like a good idea, I'll help there. Probably makes sense to have the same dialogs as exist in the legacy test app for starters, even though that might mean some redundancy in the sandbox source tree. Then we can add others to display some SCXML-specific bits. Is this similar to what you were thinking?
Yes. In a broader scope, I'd like to see us migrate test functionality that is strictly for testing out of the "use cases" app and into apps like the test ones (shale-test-core and shale-test-tiger in framework/shale-apps, and shale-test-dialog2-legacy in sandbox). That way, we could make room in the use cases app for stuff with visual appeal (and explanatory backup info) for demos or a quick learning experience. Craig -Rahul
> > Craig > >
