Re: [cforms] New ProcessingPhases added a repeater bug?
Carsten Ziegeler escribió: Antonio Gallardo wrote: It's not it does not work. The code was moved out because this seems to be a better place for firing form events. This events are form events, hence the form should fire them as needed. IMHO, the binding framework does not need to know/care about special form needs. Agreed This can be fixed in a different way: While fixing this issue. We wondered why form.save() and form.load() methods are defined only in form.js . This make pretty complicated to call the binding framework outside flow (ie: from the actions). IMHO, this methods belongs to form.java and in this way we can also not allow an outsider class to call the following public methods: informStartLoadingModel() informEndLoadingModel() informStartSavingModel() informEndSavingModel() WDYT? Hmm, ok it sounds good to me to move code out of form.js into the Java code. I think most of the code from form.js should be moved to be available for cforms clients which do not use flow. And protecting the above methods is good as well. The only thing I do not know is if it is a good idea to add a dependency to the binding package to the form class. So a general +1 for this. There are 2 very close file that we need to merge first: Form.js [1] for js flow and FormInstance.java [2] for javaflow The later seems to be lagging new functionality. But both files needs to provide the same functionality. BTW, an interesting outdated patch [3] Do you have an idea how to solve this? Best Regards, Antonio Gallardo [1] src/blocks/forms/resources/org/apache/cocoon/forms/flow/javascript/Form.js [2] src/blocks/javaflow/java/org/apache/cocoon/forms/flow/java/FormInstance.java [3] http://issues.apache.org/jira/browse/COCOON-844 Carsten
Re: [cforms] New ProcessingPhases added a repeater bug?
Antonio Gallardo wrote: There are 2 very close file that we need to merge first: Form.js [1] for js flow and FormInstance.java [2] for javaflow The later seems to be lagging new functionality. But both files needs to provide the same functionality. BTW, an interesting outdated patch [3] Do you have an idea how to solve this? I think, we should merge Form.js with the Form class first. Then we can apply those changes to FormInstance.java. The FormInstance class is outdated and has not been maintained so I guess it's safe to overwrite everything what is in there with newer stuff. I guess the patch is also obsolete then as we cover all features from the patch in a slightly different fashion. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [cforms] New ProcessingPhases added a repeater bug?
Antonio Gallardo wrote: Hi Leo, Thanks for the input! It's now fixed: http://svn.apache.org/viewvc?rev=414691view=rev Can you please explain why it works if the events are fired from flowscript and why it does not work if they're fired from the binding framework. I think we should try to fire the events from the binding framework because if someone is not using flowscript, the behaviour should be the same. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [cforms] New ProcessingPhases added a repeater bug?
Carsten Ziegeler escribió: Antonio Gallardo wrote: Hi Leo, Thanks for the input! It's now fixed: http://svn.apache.org/viewvc?rev=414691view=rev Hi Carsten, Thanks for taking your time for reviewing this. :-) Can you please explain why it works if the events are fired from flowscript and why it does not work if they're fired from the binding framework. It's not it does not work. The code was moved out because this seems to be a better place for firing form events. This events are form events, hence the form should fire them as needed. IMHO, the binding framework does not need to know/care about special form needs. I think we should try to fire the events from the binding framework because if someone is not using flowscript, the behaviour should be the same. This can be fixed in a different way: While fixing this issue. We wondered why form.save() and form.load() methods are defined only in form.js . This make pretty complicated to call the binding framework outside flow (ie: from the actions). IMHO, this methods belongs to form.java and in this way we can also not allow an outsider class to call the following public methods: informStartLoadingModel() informEndLoadingModel() informStartSavingModel() informEndSavingModel() WDYT? Best Regards, Antonio Gallardo
Re: [cforms] New ProcessingPhases added a repeater bug?
Antonio Gallardo wrote: It's not it does not work. The code was moved out because this seems to be a better place for firing form events. This events are form events, hence the form should fire them as needed. IMHO, the binding framework does not need to know/care about special form needs. Agreed This can be fixed in a different way: While fixing this issue. We wondered why form.save() and form.load() methods are defined only in form.js . This make pretty complicated to call the binding framework outside flow (ie: from the actions). IMHO, this methods belongs to form.java and in this way we can also not allow an outsider class to call the following public methods: informStartLoadingModel() informEndLoadingModel() informStartSavingModel() informEndSavingModel() WDYT? Hmm, ok it sounds good to me to move code out of form.js into the Java code. I think most of the code from form.js should be moved to be available for cforms clients which do not use flow. And protecting the above methods is good as well. The only thing I do not know is if it is a good idea to add a dependency to the binding package to the form class. So a general +1 for this. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [cforms] New ProcessingPhases added a repeater bug?
On Jun 14, 2006, at 11:06 PM, Antonio Gallardo wrote: Hi folks, Carlos and I suspect we hit a recently introduced bug. Steps to reproduce == 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/ blocks/forms/form2bean.flow 2. Change birthday date to a valid date (just changing the year to 2000 is enough). 3. Delete the unique contact in the repeater. 4. Now press Add contact. 6. Fill the firstname (an a is enough). 7. Save the form (press send button). Comments We suspect the error was introduced in revision 410241 [1]. Can anyone reproduce the bug and confirm the issue? Yes, I can. The Task Tree sample is another Cocoon sample to reproduce the problem: 3-Steps-Way to reproduce 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/blocks/ forms/do-taskTree.flow 2. Fill the 'Project name' (an a is enough). 3. Save the form (press OK button). /Leo = java.lang.IllegalStateException: Cannot save model in phase ProcessingPhase[Save model=3] org.apache.cocoon.ProcessingException: Error calling continuation at resource://org/apache/cocoon/forms/flow/javascript/Form.js:256:-1 at file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/ samples/blocks/forms/flow/forms_flow_example.js:172:-1 at map:call - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/samples/blocks/forms/sitemap.xmap:180:38 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/samples/blocks/sitemap.xmap:66:68 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/samples/sitemap.xmap:201:65 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/sitemap.xmap:1017:92 at org.apache.cocoon.ProcessingException.throwLocated (ProcessingException.java:144) at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.ge tException(LocationTrackingDebugger.java:131) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret er.handleContinuation(FOM_JavaScriptInterpreter.java:840) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invo ke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:142) at
Re: [cforms] New ProcessingPhases added a repeater bug?
Leo Leonid escribió: On Jun 14, 2006, at 11:06 PM, Antonio Gallardo wrote: Hi folks, Carlos and I suspect we hit a recently introduced bug. Steps to reproduce == 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form2bean.flow 2. Change birthday date to a valid date (just changing the year to 2000 is enough). 3. Delete the unique contact in the repeater. 4. Now press Add contact. 6. Fill the firstname (an a is enough). 7. Save the form (press send button). Comments We suspect the error was introduced in revision 410241 [1]. Can anyone reproduce the bug and confirm the issue? Yes, I can. The Task Tree sample is another Cocoon sample to reproduce the problem: 3-Steps-Way to reproduce 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-taskTree.flow 2. Fill the 'Project name' (an a is enough). 3. Save the form (press OK button). Hi Leo, Thanks for the input! It's now fixed: http://svn.apache.org/viewvc?rev=414691view=rev Best Regards, Antonio Gallardo
[cforms] New ProcessingPhases added a repeater bug?
Hi folks, Carlos and I suspect we hit a recently introduced bug. Steps to reproduce == 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form2bean.flow 2. Change birthday date to a valid date (just changing the year to 2000 is enough). 3. Delete the unique contact in the repeater. 4. Now press Add contact. 6. Fill the firstname (an a is enough). 7. Save the form (press send button). Comments We suspect the error was introduced in revision 410241 [1]. Can anyone reproduce the bug and confirm the issue? Best Regards, Antonio Gallardo [1] http://svn.apache.org/viewvc?rev=410241view=rev * Full stacktrace org.apache.cocoon.ProcessingException: Error calling continuation at resource://org/apache/cocoon/forms/flow/javascript/Form.js:256:-1 at file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/forms/flow/binding_example.js:89:-1 at resource://org/apache/cocoon/forms/flow/javascript/Form.js:0:-1 at map:call - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/forms/sitemap.xmap:180:38 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/sitemap.xmap:66:68 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/sitemap.xmap:201:65 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/sitemap.xmap:1017:92 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:144) at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.getException(LocationTrackingDebugger.java:131) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:840) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at
