You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Nestor Urquiza <ne...@yahoo.com> on 2007/01/05 15:17:54 UTC
Re: [scxml] including chunks of scxml code.
Hi,
I am sorry I could not reply before. Then,
Using templating thru //state/@src is useful for
including reusable FSM as mean of whole states.
XInclude/XML Entities are useful for including chunks
of SCXML logic.
I am not sure how the first works but seems like
commons-scxml would parse just once those states
defined within the reusable FSM. For the second one I
think it complies with DRY principles, however since
including nodes means more processing for either SAX
or DOM parser I would predict some performance
degradation (the same in comparison to just copying
and pasting the bits within the main SCXML file
though).
The question of course is if SCXML provides a way/tag
for real code reuse either templating or functions
that can be used "for any arbitrary bits or pieces". I
can read from [1]
"Note that the <invoke> element may be used to invoke
an external SCXML interpreter to execute a different
state machine. In this case, the external state
machine acts as a set of substates of the invoking
state. The behavior is thus similar to a complex state
defined with <state> child elements. The most
important difference is that in the <invoke> case, the
external state machine does not share context with the
invoking machine. In particular, the invoked machine
cannot access any variables declared in the invoking
machine and data can be shared only by being
explicitly passed via the <param> element.
Furthermore, IDs need not be distinct across the two
machines (though they must, of course, be distinct
within each machine.) The <invoke> tag thus provides a
means of well-encapsulated code reuse."
Can anyone offer some snippet of code to solve let us
say the following simple example of code reuse?
usecase: Build a template/function that returns the
name of the pet knowing that:
if animal type="dog" then name="Fido"
if animal type="cat" then name="Kitty"
if animal type="bird" then name="Tweety"
if animal type="horse" then name="Trigger"
if animal type="cat" then name="Tom"
if animal type="pig" then name="Porky"
if animal type="fish" then name="Charlie"
if animal type="pig" then name="Babe"
if animal type="cow" then name="Elsie"
if animal type="cat" then name="Puss"
Of course using <invoke> and <finalize> it seems to be
possible to accomplish this but I am wondering if
someone already used them or simply someone can write
down the snippet of code that actually works while
using of course commons-scxml.
Thanks,
-Nestor
[1] http://www.w3.org/TR/scxml/
--- Rahul Akolkar <ra...@gmail.com> wrote:
> On 11/1/06, Craig McClanahan <cr...@apache.org>
> wrote:
> > On 11/1/06, Nestor Urquiza <ne...@yahoo.com>
> wrote:
> > >
> > > Hello guys,
> > >
> > > I need to apply DRY ;-) so I do not want to be
> > > duplicating SCXML code that is to be included in
> many
> > > different states.
> > >
> > > Just wondering about the options we have here:
> > >
> > > 1)XInclude
> > > 2)A special tag from scxml???
> > > 3) Any other idea?
> >
> >
> > XML entities?
> >
> <snip/>
>
> This will work well for any abitrary bits and
> pieces, the earlier
> solution is just for <state>s. But if you choose
> this, you'll have to
> worry about duplicating state IDs, if the bits and
> pieces contain
> those.
>
> -Rahul
>
>
> > Thanks,
> > >
> > > -Nestor
> >
> >
> > Craig
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] including chunks of scxml code.
Posted by Nestor Urquiza <ne...@yahoo.com>.
I'll go for Entities and in the meanwhile I'll
request/suggest to SCXML spec to include at least one
way for code reuse thru functions/templates.
Thanks,
-Nestor
--- Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/5/07, Nestor Urquiza <ne...@yahoo.com> wrote:
> > Hi Rahul,
> >
> > While java can be used of course and I use it for
> a
> > lot of helper methods like the one you propose for
> the
> > given example, it breaks the needed separation of
> > concerns for my case.
> >
> <snip-example/>
> >
> > While of course the example is simple to
> illustrate
> > the need the bottom line is that I want to use
> (and I
> > am using) commons-scxml as a Controller and so
> > business rules (very complex ones) can be added
> > without recompilation or java releases, accesible
> to
> > operations guys that are very close to business
> people
> > and far away from software developers.
> >
> <snap/>
>
> There was a suggestion about XML entities; that is
> one possibility to
> avoid recompilation, and works for executable
> content (where IDs are
> not used).
>
>
> > So, from your reply I understand commons-scxml
> does
> > not implement <invoke> still. We have to wait for
> an
> > agreement from W3C for invoke final implementation
> > right?
> >
> <snip/>
>
> <invoke> is in place, its just not advertised very
> much since we know
> it may change. For example, you can register an
> invoker class for a
> given targettype on the executor (see SCXMLExecutor
> Javadoc and follow
> along from the registerInvokerClass() method).
>
>
> > Just thinking aloud, I would expect SCXML to have
> > features like XSLT templating which is nothing but
> the
> > ability to reuse code thru functions. What you
> think?
> >
> <snap/>
>
> All ideas are welcome. Some may be suitable for the
> spec (and won't be
> handled here, unlike those for the impl).
>
> -Rahul
>
>
> > Thanks a bunch,
> >
> > -Nestor
> >
> >
> <snip/>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] including chunks of scxml code.
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/5/07, Nestor Urquiza <ne...@yahoo.com> wrote:
> Hi Rahul,
>
> While java can be used of course and I use it for a
> lot of helper methods like the one you propose for the
> given example, it breaks the needed separation of
> concerns for my case.
>
<snip-example/>
>
> While of course the example is simple to illustrate
> the need the bottom line is that I want to use (and I
> am using) commons-scxml as a Controller and so
> business rules (very complex ones) can be added
> without recompilation or java releases, accesible to
> operations guys that are very close to business people
> and far away from software developers.
>
<snap/>
There was a suggestion about XML entities; that is one possibility to
avoid recompilation, and works for executable content (where IDs are
not used).
> So, from your reply I understand commons-scxml does
> not implement <invoke> still. We have to wait for an
> agreement from W3C for invoke final implementation
> right?
>
<snip/>
<invoke> is in place, its just not advertised very much since we know
it may change. For example, you can register an invoker class for a
given targettype on the executor (see SCXMLExecutor Javadoc and follow
along from the registerInvokerClass() method).
> Just thinking aloud, I would expect SCXML to have
> features like XSLT templating which is nothing but the
> ability to reuse code thru functions. What you think?
>
<snap/>
All ideas are welcome. Some may be suitable for the spec (and won't be
handled here, unlike those for the impl).
-Rahul
> Thanks a bunch,
>
> -Nestor
>
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] including chunks of scxml code.
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/5/07, Nestor Urquiza <ne...@yahoo.com> wrote:
> Another interesting tag is <script> which eventually
> would allow to accomplish any complex calculations and
> of course supports functions because it uses
> ECMAScript however I read at w3c:
>
> "<script> is included for reasons of backward
> compatability with CCXML. It may be removed in future
> versions of this document."
>
> Any comments on that matter?
>
<snip/>
I'm interested in seeing whether it persists in future versions of the
document :-) I think future versions will not mandate impls to have
it, but we can do it here at Commons if there is sufficient interest.
-Rahul
> Thanks,
>
> -Nestor
>
<snap/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] including chunks of scxml code.
Posted by Nestor Urquiza <ne...@yahoo.com>.
Another interesting tag is <script> which eventually
would allow to accomplish any complex calculations and
of course supports functions because it uses
ECMAScript however I read at w3c:
"<script> is included for reasons of backward
compatability with CCXML. It may be removed in future
versions of this document."
Any comments on that matter?
Thanks,
-Nestor
--- Nestor Urquiza <ne...@yahoo.com> wrote:
> Hi Rahul,
>
> While java can be used of course and I use it for a
> lot of helper methods like the one you propose for
> the
> given example, it breaks the needed separation of
> concerns for my case.
>
> The rule about the name of the pet can change
> tomorrow
> when a new parameter is added to the equation, let
> us
> say the owner:
>
> if animal type="dog" and owner="Mike" then
> name="Fido"
> if animal type="dog" and owner="Tom" then
> name="Rudolph"
>
> And I do not want to overload a java method for that
> matter specially if the rule will change again next
> week.
>
> While of course the example is simple to illustrate
> the need the bottom line is that I want to use (and
> I
> am using) commons-scxml as a Controller and so
> business rules (very complex ones) can be added
> without recompilation or java releases, accesible to
> operations guys that are very close to business
> people
> and far away from software developers.
>
> For those cases in which business rules change very
> easy and even in a daily basis it is better to give
> business people the power to change the functional
> behavior of the package. I use java for the model
> and
> JEXL with basic helper methods (built in java) and
> accessible from SCXML for the controller part.
>
> Since I have a system that is *dynamically*
> configured,
> I need some "power features" at the level of SCXML
> like code reuse thru functions.
>
> So, from your reply I understand commons-scxml does
> not implement <invoke> still. We have to wait for an
> agreement from W3C for invoke final implementation
> right?
>
> Just thinking aloud, I would expect SCXML to have
> features like XSLT templating which is nothing but
> the
> ability to reuse code thru functions. What you
> think?
>
> Thanks a bunch,
>
> -Nestor
>
>
>
> --- Rahul Akolkar <ra...@gmail.com> wrote:
>
> > On 1/5/07, Nestor Urquiza <ne...@yahoo.com>
> wrote:
> > > Hi,
> > > I am sorry I could not reply before. Then,
> > >
> > <snip/>
> >
> > No rush at all :-)
> >
> >
> > > Using templating thru //state/@src is useful for
> > > including reusable FSM as mean of whole states.
> > >
> > > XInclude/XML Entities are useful for including
> > chunks
> > > of SCXML logic.
> > >
> > > I am not sure how the first works but seems like
> > > commons-scxml would parse just once those states
> > > defined within the reusable FSM. For the second
> > one I
> > > think it complies with DRY principles, however
> > since
> > > including nodes means more processing for either
> > SAX
> > > or DOM parser I would predict some performance
> > > degradation (the same in comparison to just
> > copying
> > > and pasting the bits within the main SCXML file
> > > though).
> > >
> > <snap/>
> >
> > Possibly, though its a one time cost (not per
> > instance of state machine).
> >
> >
> > > The question of course is if SCXML provides a
> > way/tag
> > > for real code reuse either templating or
> functions
> > > that can be used "for any arbitrary bits or
> > pieces". I
> > > can read from [1]
> > >
> > <snip-invoke-quote/>
> >
> > The invoke tag is too heavyweight for the example
> > below, and it is not
> > completely fleshed out in the spec yet (as
> mentioned
> > on Commons SCXML
> > homepage).
> >
> >
> > > Can anyone offer some snippet of code to solve
> let
> > us
> > > say the following simple example of code reuse?
> > >
> > > usecase: Build a template/function that returns
> > the
> > > name of the pet knowing that:
> > > if animal type="dog" then name="Fido"
> > > if animal type="cat" then name="Kitty"
> > > if animal type="bird" then name="Tweety"
> > > if animal type="horse" then name="Trigger"
> > > if animal type="cat" then name="Tom"
> > > if animal type="pig" then name="Porky"
> > > if animal type="fish" then name="Charlie"
> > > if animal type="pig" then name="Babe"
> > > if animal type="cow" then name="Elsie"
> > > if animal type="cat" then name="Puss"
> > >
> > > Of course using <invoke> and <finalize> it seems
> > to be
> > > possible to accomplish this but I am wondering
> if
> > > someone already used them or simply someone can
> > write
> > > down the snippet of code that actually works
> while
> > > using of course commons-scxml.
> > >
> > <snap/>
> >
> > For such bits, define functions in your own
> > namespace (see bottom of
> > this page [A] ). The above pseudo could be the
> body
> > of:
> >
> > public String petName(String species) { ... }
> >
> > whereby the name is obtained within executable
> > content in the SCXML document as:
> >
> > <var name="pet" expr="${myfn:petName(type)}"/>
> (EL)
> >
> > <var name="pet" expr="myfn.petName(type)"/>
> (JEXL)
> >
> > This puts the procedural bits in a Java class,
> makes
> > them reusable etc.
> >
> > -Rahul
> >
> > [A]
> >
>
http://jakarta.apache.org/commons/scxml/guide/contexts-evaluators.html
> >
> >
> >
> > > Thanks,
> > >
> > > -Nestor
> > >
> > > [1] http://www.w3.org/TR/scxml/
> > >
> > >
> > > --- Rahul Akolkar <ra...@gmail.com>
> wrote:
> > >
> > > > On 11/1/06, Craig McClanahan
> > <cr...@apache.org>
> > > > wrote:
> > > > > On 11/1/06, Nestor Urquiza
> <ne...@yahoo.com>
> > > > wrote:
> > > > > >
> > > > > > Hello guys,
> > > > > >
> > > > > > I need to apply DRY ;-) so I do not want
> to
> > be
> > > > > > duplicating SCXML code that is to be
> > included in
> > > > many
> > > > > > different states.
> > > > > >
> > > > > > Just wondering about the options we have
> > here:
> > > > > >
> > > > > > 1)XInclude
> > > > > > 2)A special tag from scxml???
> > > > > > 3) Any other idea?
> > > > >
> > > > >
> > > > > XML entities?
> > > > >
> > > > <snip/>
> > > >
> > > > This will work well for any abitrary bits and
> > > > pieces, the earlier
> > > > solution is just for <state>s. But if you
> choose
> > > > this, you'll have to
> > > > worry about duplicating state IDs, if the bits
> > and
> > > > pieces contain
> > > > those.
> > > >
> > > > -Rahul
> > > >
> > > >
> > > > > Thanks,
> > > > > >
> > > > > > -Nestor
> > > > >
> > > > >
> > > > > Craig
> > > > >
> > > > >
> > > >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-user-help@jakarta.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] including chunks of scxml code.
Posted by Nestor Urquiza <ne...@yahoo.com>.
Hi Rahul,
While java can be used of course and I use it for a
lot of helper methods like the one you propose for the
given example, it breaks the needed separation of
concerns for my case.
The rule about the name of the pet can change tomorrow
when a new parameter is added to the equation, let us
say the owner:
if animal type="dog" and owner="Mike" then name="Fido"
if animal type="dog" and owner="Tom" then
name="Rudolph"
And I do not want to overload a java method for that
matter specially if the rule will change again next
week.
While of course the example is simple to illustrate
the need the bottom line is that I want to use (and I
am using) commons-scxml as a Controller and so
business rules (very complex ones) can be added
without recompilation or java releases, accesible to
operations guys that are very close to business people
and far away from software developers.
For those cases in which business rules change very
easy and even in a daily basis it is better to give
business people the power to change the functional
behavior of the package. I use java for the model and
JEXL with basic helper methods (built in java) and
accessible from SCXML for the controller part.
Since I have a system that is *dynamically*
configured,
I need some "power features" at the level of SCXML
like code reuse thru functions.
So, from your reply I understand commons-scxml does
not implement <invoke> still. We have to wait for an
agreement from W3C for invoke final implementation
right?
Just thinking aloud, I would expect SCXML to have
features like XSLT templating which is nothing but the
ability to reuse code thru functions. What you think?
Thanks a bunch,
-Nestor
--- Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/5/07, Nestor Urquiza <ne...@yahoo.com> wrote:
> > Hi,
> > I am sorry I could not reply before. Then,
> >
> <snip/>
>
> No rush at all :-)
>
>
> > Using templating thru //state/@src is useful for
> > including reusable FSM as mean of whole states.
> >
> > XInclude/XML Entities are useful for including
> chunks
> > of SCXML logic.
> >
> > I am not sure how the first works but seems like
> > commons-scxml would parse just once those states
> > defined within the reusable FSM. For the second
> one I
> > think it complies with DRY principles, however
> since
> > including nodes means more processing for either
> SAX
> > or DOM parser I would predict some performance
> > degradation (the same in comparison to just
> copying
> > and pasting the bits within the main SCXML file
> > though).
> >
> <snap/>
>
> Possibly, though its a one time cost (not per
> instance of state machine).
>
>
> > The question of course is if SCXML provides a
> way/tag
> > for real code reuse either templating or functions
> > that can be used "for any arbitrary bits or
> pieces". I
> > can read from [1]
> >
> <snip-invoke-quote/>
>
> The invoke tag is too heavyweight for the example
> below, and it is not
> completely fleshed out in the spec yet (as mentioned
> on Commons SCXML
> homepage).
>
>
> > Can anyone offer some snippet of code to solve let
> us
> > say the following simple example of code reuse?
> >
> > usecase: Build a template/function that returns
> the
> > name of the pet knowing that:
> > if animal type="dog" then name="Fido"
> > if animal type="cat" then name="Kitty"
> > if animal type="bird" then name="Tweety"
> > if animal type="horse" then name="Trigger"
> > if animal type="cat" then name="Tom"
> > if animal type="pig" then name="Porky"
> > if animal type="fish" then name="Charlie"
> > if animal type="pig" then name="Babe"
> > if animal type="cow" then name="Elsie"
> > if animal type="cat" then name="Puss"
> >
> > Of course using <invoke> and <finalize> it seems
> to be
> > possible to accomplish this but I am wondering if
> > someone already used them or simply someone can
> write
> > down the snippet of code that actually works while
> > using of course commons-scxml.
> >
> <snap/>
>
> For such bits, define functions in your own
> namespace (see bottom of
> this page [A] ). The above pseudo could be the body
> of:
>
> public String petName(String species) { ... }
>
> whereby the name is obtained within executable
> content in the SCXML document as:
>
> <var name="pet" expr="${myfn:petName(type)}"/> (EL)
>
> <var name="pet" expr="myfn.petName(type)"/> (JEXL)
>
> This puts the procedural bits in a Java class, makes
> them reusable etc.
>
> -Rahul
>
> [A]
>
http://jakarta.apache.org/commons/scxml/guide/contexts-evaluators.html
>
>
>
> > Thanks,
> >
> > -Nestor
> >
> > [1] http://www.w3.org/TR/scxml/
> >
> >
> > --- Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > > On 11/1/06, Craig McClanahan
> <cr...@apache.org>
> > > wrote:
> > > > On 11/1/06, Nestor Urquiza <ne...@yahoo.com>
> > > wrote:
> > > > >
> > > > > Hello guys,
> > > > >
> > > > > I need to apply DRY ;-) so I do not want to
> be
> > > > > duplicating SCXML code that is to be
> included in
> > > many
> > > > > different states.
> > > > >
> > > > > Just wondering about the options we have
> here:
> > > > >
> > > > > 1)XInclude
> > > > > 2)A special tag from scxml???
> > > > > 3) Any other idea?
> > > >
> > > >
> > > > XML entities?
> > > >
> > > <snip/>
> > >
> > > This will work well for any abitrary bits and
> > > pieces, the earlier
> > > solution is just for <state>s. But if you choose
> > > this, you'll have to
> > > worry about duplicating state IDs, if the bits
> and
> > > pieces contain
> > > those.
> > >
> > > -Rahul
> > >
> > >
> > > > Thanks,
> > > > >
> > > > > -Nestor
> > > >
> > > >
> > > > Craig
> > > >
> > > >
> > >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [scxml] including chunks of scxml code.
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/5/07, Nestor Urquiza <ne...@yahoo.com> wrote:
> Hi,
> I am sorry I could not reply before. Then,
>
<snip/>
No rush at all :-)
> Using templating thru //state/@src is useful for
> including reusable FSM as mean of whole states.
>
> XInclude/XML Entities are useful for including chunks
> of SCXML logic.
>
> I am not sure how the first works but seems like
> commons-scxml would parse just once those states
> defined within the reusable FSM. For the second one I
> think it complies with DRY principles, however since
> including nodes means more processing for either SAX
> or DOM parser I would predict some performance
> degradation (the same in comparison to just copying
> and pasting the bits within the main SCXML file
> though).
>
<snap/>
Possibly, though its a one time cost (not per instance of state machine).
> The question of course is if SCXML provides a way/tag
> for real code reuse either templating or functions
> that can be used "for any arbitrary bits or pieces". I
> can read from [1]
>
<snip-invoke-quote/>
The invoke tag is too heavyweight for the example below, and it is not
completely fleshed out in the spec yet (as mentioned on Commons SCXML
homepage).
> Can anyone offer some snippet of code to solve let us
> say the following simple example of code reuse?
>
> usecase: Build a template/function that returns the
> name of the pet knowing that:
> if animal type="dog" then name="Fido"
> if animal type="cat" then name="Kitty"
> if animal type="bird" then name="Tweety"
> if animal type="horse" then name="Trigger"
> if animal type="cat" then name="Tom"
> if animal type="pig" then name="Porky"
> if animal type="fish" then name="Charlie"
> if animal type="pig" then name="Babe"
> if animal type="cow" then name="Elsie"
> if animal type="cat" then name="Puss"
>
> Of course using <invoke> and <finalize> it seems to be
> possible to accomplish this but I am wondering if
> someone already used them or simply someone can write
> down the snippet of code that actually works while
> using of course commons-scxml.
>
<snap/>
For such bits, define functions in your own namespace (see bottom of
this page [A] ). The above pseudo could be the body of:
public String petName(String species) { ... }
whereby the name is obtained within executable content in the SCXML document as:
<var name="pet" expr="${myfn:petName(type)}"/> (EL)
<var name="pet" expr="myfn.petName(type)"/> (JEXL)
This puts the procedural bits in a Java class, makes them reusable etc.
-Rahul
[A] http://jakarta.apache.org/commons/scxml/guide/contexts-evaluators.html
> Thanks,
>
> -Nestor
>
> [1] http://www.w3.org/TR/scxml/
>
>
> --- Rahul Akolkar <ra...@gmail.com> wrote:
>
> > On 11/1/06, Craig McClanahan <cr...@apache.org>
> > wrote:
> > > On 11/1/06, Nestor Urquiza <ne...@yahoo.com>
> > wrote:
> > > >
> > > > Hello guys,
> > > >
> > > > I need to apply DRY ;-) so I do not want to be
> > > > duplicating SCXML code that is to be included in
> > many
> > > > different states.
> > > >
> > > > Just wondering about the options we have here:
> > > >
> > > > 1)XInclude
> > > > 2)A special tag from scxml???
> > > > 3) Any other idea?
> > >
> > >
> > > XML entities?
> > >
> > <snip/>
> >
> > This will work well for any abitrary bits and
> > pieces, the earlier
> > solution is just for <state>s. But if you choose
> > this, you'll have to
> > worry about duplicating state IDs, if the bits and
> > pieces contain
> > those.
> >
> > -Rahul
> >
> >
> > > Thanks,
> > > >
> > > > -Nestor
> > >
> > >
> > > Craig
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org