Grzegorz Kossakowski wrote:
Instead, I would simply like to see map:call expanded so that the
target function can be a bit more generic than an Interpreter (i.e -
it is easier to implement things like the JSF block, which uses an
action or Spring webflow).
What more generic than Interpreter interface you need?
Good question. Unfortunately, I haven't had a huge amount of time to see
what it would really take to invoke Spring webflow this way. However, it
certainly doesn't have continuations, so I doubt handleContinuation is
of much use. On the other hand, webflow does have event ids that need to
be passed in.
I also notice that (at least in 2.1) you have to declare
<flow-interpreters default="javascript" logger="flow">
<!-- FOM (Flow Object Model) -->
<component-instance
class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter"
name="javascript">
<load-on-startup>resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js</load-on-startup>
<reload-scripts>${javascript.reload-scripts}</reload-scripts>
<check-time>${javascript.check-time}</check-time>
<!-- <debugger>enabled</debugger> --> <!-- JavaScript Debugger
support -->
</component-instance>
</flow-interpreters>
in cocoon.xconf and then add
<map:flow language="javascript">
<map:script src="calc.js"/>
</map:flow>
to your sitemap for this to work. webflow wouldn't have a "script".
Instead it would have a flow configuration. This could be similar enough
that it would work, but it would feel weird to have to code
language="webflow".
Ralph
