How do I put standard webflow RequestContext as argument to pojo method?

[Keith Donald]

Hmmm... interesting idea.

Why would the event be needed?

Currently the ExternalContext object is aware of external scopes. There could certainly be some scope accessor helper there, up to an ExternalContext impl to implement as they see fit. Beyond that, I'm not sure, as we'd be mixing SWF internal scopes (accessible via the RequestContext) with externally-managed scopes (not under the control of SWF).

Keith

[dhewitt]

Why would the event be needed?

It was late, brain was addled, I was thinking of the RequestContext...

Currently the ExternalContext object is aware of external scopes. There could certainly be some scope accessor helper there, up to an ExternalContext impl to implement as they see fit. Beyond that, I'm not sure, as we'd be mixing SWF internal scopes (accessible via the RequestContext) with externally-managed scopes (not under the control of SWF).

I think there might be some value in providing a unified view of the scopes available on the RequestContext itself. Maybe rather than get/setAttribute as I suggested earlier, you just have:

 AttributeMap getScope(String scopeName)

You would replace three methods on RequestContext with one. If it doesn't find a scope, it can delegate to the ExternalContext, which again would replace three other, different methods with one with the same signature as above. Then you leave the possibility open to plug in different scopes to the framework at any level, to cope with external requirements like Portlets (as above) or to cope with esoteric user flow requirements like, say, three collaborating conversations sharing a distinct scope.

[bowa]

In the method exposed to ajax calls by DWR i have this code already

		WebContext ctx = WebContextFactory.get();
		
		FlowExecutorArgumentExtractor flowExecutorArgumentExtractor = 
			new FlowExecutorArgumentExtractor();
		
		ServletExternalContext servletExternalContext = 
			new ServletExternalContext(
					ctx.getServletContext(),
					ctx.getHttpServletRequest(),
					ctx.getHttpServletResponse());
		
		Serializable conversationId = flowExecutorArgumentExtractor
			.extractConversationId(servletExternalContext);

The problem with this is that the conversationId is null.

I guess this is because the ServletExternalContext is build from the servletcontext and request en response object of the call to the DWR ajax controller ... and the argumentExtractor probably tries to find the conversationId inthere.

So an alternative way would be to pass on the conversationId to the ajax method from the view-state. Is the conversationId already available during the execution of my method in my MultiAction bean, so i could add the conversationId to the model of the view ?

[Keith Donald]

Well, yes, the conversationId has to be submitted in the Ajax request. There is simply no way around that.

It's always available in the FlowExecutionKey, which is made available to every view rendered from a view state. I'm not sure what your sequence events is (e.g how your flow interacts with your Ajax controller), but you most definitely have to get a hold of the conversationId for the conversation you want to interact with.

Keith

[Keith Donald]

Dave I think your suggestion is a good one; however, I don't think we should remove the specfic scope accessor methods we have now--those are quite convenient for programmatic usage.

I'm also a bit conflicted about using a String their for a scope name, when we have the ScopeType constant (which really refers to just internal SWF scope types, not external map scope types).

It seems pretty clear an ExternalMap.getScope(String scopeName) method makes good sense and should be sufficiently generic. I'm just not entirely convinced about such a method on the RequestContext.

Keith

[bowa]

ok so i ll just pass on the Key then to the ajax method and there i ll get the conversationId out of the Key using pattern matching.

Pattern pattern = Pattern.compile("^_s(.*)_c(.*)$");
Matcher matcher = pattern.matcher(flowExecutionKeyString);

String conversationId = null;

if ( matcher.matches() )
	conversationId = matcher.group(1);

WebContext ctx = WebContextFactory.get();

ExternalContext externalContext = new ServletExternalContext(
		ctx.getServletContext(),
		ctx.getHttpServletRequest(),
		ctx.getHttpServletResponse());

FlowExecutionRepository flowExecutionRepository = 
	flowExecutionRepositoryFactory.getRepository(externalContext);

FlowExecutionKey flowExecutionKey = 
	flowExecutionRepository.getCurrentFlowExecutionKey(conversationId);

logger.debug("flowExecutionKey " + flowExecutionKey);

FlowExecution flowExecution = 
	flowExecutionRepository.getFlowExecution(flowExecutionKey);

logger.debug("flowExecution " + flowExecution.getCaption());

AttributeMap scope = flowExecution.getScope();

logger.debug("scope size" + scope.size());

the debugger output gives ...

- <flowExecutionKey [FlowExecutionKey@96bf47 conversationId = '93D40ED5-B669-2AE8-0C14-7CCC197B97E4', continuationId = '2FB2877E-54B8-F424-C170-FDB4B5EE86EB']>
- <flowExecution FlowExecution:flow=[upgradedowngradeWebflow]>
- <scope size0>

so it finds the Key ( with the right continuationId ... ) and it finds the right FlowExecution.

but why is the scope size 0 ???

while in the formAction i have put objects into the FlowScope ...

requestContext.getFlowScope().put("myOptions", myOptions);

and i was able to retrieve that object in the view from the model.

am i accessing the wrong 'scope' here ??

[Keith Donald]

Yes you're accessing the wrong scope. You want flowExecution.getActiveSession().getScope(). See the docs for the differences.

You really should write out and submti back the conversationId instead of relying on parsing the flow execution key like that--your controller seems a little brittle elsewise.

[bowa]

ok sorry ... had to use

AttributeMap scope = flowExecution.getActiveSession().getScope();

instead of

AttributeMap scope = flowExecution.getScope();

[garpinc2]

Sounds like you guys are on right track...

ExternalMap.getScope(String scopeName)

My 2 cents is whatever makes api simpler and code and flow defs easy to understand. I'm ok with redundant helper scope variables to make code easier to understand and prevent strange syntax to pass scope name.

What is that syntax BTW. How would proposed solution look like in flow definition?

[Keith Donald]

probably:
${externalContext.scopeName.foo}

Keith