commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nestor Urquiza <nest...@yahoo.com>
Subject Re: [scxml] SCXMLExecutor#getSCInstance ... any chance to make it public?
Date Thu, 20 Apr 2006 11:05:40 GMT
I put the example in my last response to Faish and of
course if having the getter
SCXMLExecutor#getRootContext() can be avoided for my
use case I rather do it.

I am using a propietary kind of servlet container and
the way context is managed is with a simple Map but I
would really like to have my code at "bridge" level
not dependant on this particular servlet
implementation. I can even put the rootCtx in the
context as I am doing with my exec in the "system"
(also called most recently "domain" by you) layer
because the main problem of course is that it is not
enough to have the exec object if I want to manipulate
the root context.

So given those facts do you have an alternative for my
usecase other than making available
SCXMLExecutor#getRootContext()?
Thanks!

--- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:

> On 4/19/06, Nestor Urquiza <nestoru@yahoo.com>
> wrote:
> > Hello,
> > I am planning to store just the SCXMLExecutor in a
> per
> > session basis.
> <snip/>
> 
> Sounds good.
> 
> 
> > Then of course I need to have access
> > from my "bridge" to SCInstance#getRootContext to
> > obtain the context needed to set variables from my
> > specific-code.
> > The problem is right now the
> > SCXMLExecutor#getSCInstance has package access
> > Can we make it public? Or there is a better way to
> > accomplish what I am trying to do???
> > Thanks a lot!
> >
> <snap/>
> 
> No, its best not made public. The SCInstance is
> really getting into
> the internals of the SCXML engine. It holds the
> references needed for
> a particular execution, the contexts and histories
> for that execution,
> and shouldn't be exposed to the casual user.
> However, for "advanced"
> usage, accessing these internals are often
> necessary, so for users who
> wish to author:
> 
>  * Custom actions
>  * Custom SCXML semantics
> 
> the SCInstance is made available via method
> signatures in the public
> contract (see SCXMLSemantics interface, and custom
> actions page in
> user guide).
> 
> The root context for an SCXML document is its link
> to the environment
> this document is being used in (i.e. the environment
> variables). It
> often merely wraps another "context" (set of
> variables). Couple of
> examples:
> 
>  * The RootContext in the o.a.c.s.env.jsp package
> wraps a JspContext,
> i.e. any variables defined in the JSP are available
> within the SCXML
> document
>  * The SessionContext in the o.a.c.s.env.faces
> package wraps a
> "session map", i.e. any attributes defined in the
> associated session
> are available within the SCXML document
> 
> The nightlies by no means provide a complete list of
> such Context
> impls, and you may have to write one if needed (but
> the impls are
> usually trivial, since they merely delegate to some
> backing
> environment context).
> 
> So, often setting variables in the root context does
> *not* involve this:
> 
> // assuming the getter method was available
> exec.getRootContext().set("foo", fooValue)
> 
> rather something like so:
> 
> <c:set var="foo" value="foovalue" /> <%-- in host
> JSP --%>
> 
> or so:
> 
> session.setAttribute("foo", foovalue); // defining
> session attribute
> 
> and that gets picked up due to the delegating root
> context.
> 
> Also, as Faish points out, the pseudo often looks
> like:
> 
> <pseudo>
> Context rootCtx = // new suitable context type
> SCXMLExecutor exec = // new executor
> exec.setRootContext(rootCtx);
> exec.setStateMachine(// parsed, procedurally
> constructed SCXML object);
> </pseudo>
> 
> We probably could have a symmetric
> SCXMLExecutor#getRootContext() to
> match the setter, but the absence of a getter
> actually encourages the
> preferred latter usages (please open a request in
> bugzilla [1] for the
> getter if you have an example of why you'd rather
> set variables using
> the former usage).
> 
> -Rahul
> 
> [1]
>
http://jakarta.apache.org/commons/sandbox/scxml/issue-tracking.html
> 
>
---------------------------------------------------------------------
> 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


Mime
View raw message