Hi Thorsten,
Well I think the suggestion-list content must be served by a different
thread. Here is my scenario in a little more detail:
I created a patch to make suggestion-lists support on-value-changed
events and they seem to work nicely. When debuging the FormInstance
class I can see how the "cocoon-ajax-continue" loop is executed every
time the fields value changes. Usually the client side suggestion-list
javascript should load the result of a cocoon pipeline with the exact
name "_cocoon/forms/suggest" into an iframe. This Iframe contains the
suggestion-list content. Since my suggestions-lists are
context-sensitive (they contain different input for different
form-states, I need to get my hands on the FormInstance object of the
parent frames pipeline. This was no problem using the code of the
SuggestionListGenerator, but when using JavaFlow this doen't work anymore :(
Here the code that puts everything into the continuation (from
AbstractContunable sendPageAndWait)
FlowHelper.setContextObject(ContextHelper.getObjectModel(context.getAvalonContext()),
bizdata);
If I add the following watch expression in the Debugger directly after
this, I can see that the FormInstance is there
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext()))
One of my counterparts is (A second JavaFlow ... didn't expect this to
work, because of the way getContext is implemented):
VarMap bizData = (VarMap)
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext()));
The other one is (A Generator using the ContinuationsManager to lookup a
WebContinuation based upon the continuation-id)
public void setup(SourceResolver resolver, Map objectModel, String
src, Parameters par) throws ProcessingException, SAXException, IOException {
super.setup(resolver, objectModel, src, par);
Request req = ObjectModelHelper.getRequest(objectModel);
String continuationId = par.getParameter("continuation-id",
req.getParameter("continuation-id"));
// The interpreter id is the sitemap's URI
String interpreterId =
SitemapParameters.getLocation(parameters).getURI();
wk = this.contManager.lookupWebContinuation(continuationId,
interpreterId);
if (wk == null || wk.disposed()) {
throw new InvalidContinuationException("Cannot get
continuation for suggestion list");
}
Continuation continuation = (Continuation) wk.getContinuation();
ContinuationContext context = (ContinuationContext)
continuation.getContext();
VarMap bizData = (VarMap)
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext()));
Form form = (Form) bizData.getMap().get("CocoonFormsInstance");
if (form == null) {
throw new ProcessingException("No form is attached to the
continuation");
}
}
unfortunately bizData is null in both cases since there is no
"cocoon.flow.context" inside the object-model.
Do I really have to store the form instances in the Session as a
workaround? Would really like to avoid this, since I have to do all the
housekeeping :(
Am I looking up something different? Is the thing the
ContinuationManager is returning really the Continuation I want?
Chris
Torsten Curdt schrieb:
On 09.05.2007, at 15:56, Christofer Dutz wrote:
I am currently having some problems with JavaFlow and SuggestionLists.
My application used to generate dynamic suggestion lists in the
"_cocoon/forms/suggest" pipeline.
Unfortunately the FormsGenerator, SuggestionListGenerator,
JXGenerator and Transformer and my custom Generator seem to be unable
to get the form instance.
I think this might be a result of the way JavaFlow deals with
Continuations (GetContext beeing implemented using
Thread.currentThread()) as the SuggestionList pipeline is served by a
different Thread.
It's been a while and I would have to dig into the code ....but are
you sure the other pipeline is served by a different thread?
A known limitation is when you use a continuation in one pipeline and
use the cocoon protocol to a pipeline that also provides creates
continuations. That aint work as you (atm) only can have one
continuation per thread. (Not that complicated to change though)