Agree about documentation. I will post my usecase
implementation whenever a finish it at least the steps
I followed to get my State Oriented Business Protocol
working. 

I think usecases are the best way to explore the
potential of an api as well as TestCases for what you
have been doing a great job. Having a junit TestCase
per class is commonly a good place to show the user
how the class is supposed to be used.

I would say that the simpler the example the better
the guide so I would build a second
StandaloneJexlExpressions2.java and
StandaloneElExpressions2.java to show for example
method invocation (at least for jexl), context
manipulation and maybe payload operations. I have a
little idea about what a payload can do for me for
executing events but an example would definetely help.
Maybe what you put in the payload object is available
within the context and therefore I do not need the
exec getter I am asking for because instead of using:
evts[0] = new TriggerEvent(this.getClass().getName(),
                  TriggerEvent.SIGNAL_EVENT, null);

I can use:
evts[0] = new TriggerEvent(this.getClass().getName(),
                  TriggerEvent.SIGNAL_EVENT,
myContextObject);

I am sorry if I did not quite get what a payload is
:-( ... maybe a future thread subject from me to come.

Commonly you do not have a lot of time to reverse
engineering and for sure more memebers of the open
community would contribute if the real power of
commons-scxml is shown in a very simple manner.

Thanks,
Nestor
--- Rahul Akolkar <[EMAIL PROTECTED]> wrote:

> On 4/19/06, Fasih <[EMAIL PROTECTED]>
> wrote:
> <snip/>
> >
> > By the way, you can look at the code from SVN. I
> couldn't find much
> > documentation, the code itself is the best guide.
> >
> <snap/>
> 
> This is true. One of the things that we'd appreciate
> feedback on is
> how the documentation can be improved. There are a
> bunch of things in
> code that are not properly documented, and there are
> bunch of things
> that unfortunately may have been taken for granted
> that need to be
> clarified.
> 
> Documentation is one of the major thrusts before a
> 1.0, so let us know
> where its missing the mark. As always, documentation
> patches are
> welcome too.
> 
> -Rahul
> 
> 
> > +Fasih
> >
> <snip/>
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to