Jeremy Quinn wrote:
Hi All,
I have some forms that used the JX Macro form generator and AJAX,
that worked before the recent update to the 2.2 version of CForms,
but fail now.
The form contains some regular text fields, a repeater with a row-add
button and a union with associated selection widget.
The repeater works fine.
The union with it's selection widget stopped working when I updated.
I can see in TCPMon, when you change the selector menu, all the right
data is submitted.
I get this error when the on-change event occurs for the union
selector :
org.apache.cocoon.forms.FormsRuntimeException: Form is not a repeater
at fd:form - file:/[blah]/forms/[blah]-model.xml:5:2
at <jx:if> - resource://org/apache/cocoon/forms/generation/
jx-macros.xml:214:54
at <ft:repeater> - file:/[blah]/forms/[blah]-template.xml:30:35
. . .
If I remove the repeater, the Union and it's selector work correctly.
I get a similar error under different circumstances.
Our pages use TimeBrowserUpdate widgets. That use the same
BrowserUpdateTransformer to update small regions of the page,
triggered by a timer on the Browser (and I still mean to commit this
once I know where to put it).
This used to work as well. Since the update however, when you use one
of these widgets in a page that also has a form that is generated
using JX Macros, you get this error on update :
org.apache.cocoon.generation.JXTemplateGenerator$JXTException:
java.lang.NullPointerException
at <jx:if> - resource://org/apache/cocoon/forms/generation/
jx-macros.xml:45:52
at <ft:widget> - file:[blah]/forms/search-advanced-
template.xml:17:55
Can you give also the first lines of the java stacktrace to know where
the NPE happens?
When the TBU updates, it sends only it's own data, not that of the form.
If you set the fd:form/@ajax to false, then the union starts working,
but the TBU still has the same error.
If you process the form using FormsTransformer instead of JXMacro
generator, then it works as expected. (You have to switch between
repeater and repeater widget, I don't know why).
I can see that the implementation of JX Macros has changed
completely, but as of yet I cannot work out the cause of the problem.
Any suggestions would be welcome.
JX macros were largely refactored, and there was a little change to
widget scoping within <ft:repeater>. This scoping defines the base
widget that is used to resolve @id attributes on template instructions,
which is also available as the ${widget} variable.
Within <ft:repeater> and before we enter <ft:repater-rows>, $widget is
now the repeater itself whereas it previously was the parent of the
repeater.
The "addcontact" widget in the dynamic_repeater sample is a good example
of this change.
We previously had
<ft:repeater id="contacts">
...
<ft:repeater-rows>
...
</ft:repeater-rows>
<ft:widget id="addcontact"/>
</ft:repeater>
whereas we now have
<ft:repeater id="contacts">
...
<ft:repeater-rows>
...
</ft:repeater-rows>
<ft:widget id="../addcontact"/>
</ft:repeater>
Can this be the cause of your problem?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
