You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Thorsten Scherler <th...@apache.org> on 2005/08/18 19:02:04 UTC
Extending usecase-fw with cforms
Hi all,
today I was trying to extend our usecase-fw with cforms. Everything was
looking great, because I could reuse all of the architecture and just
added some if/else clauses.
Now when I come to the point of creating the form instance I always get
an exception (see stack ->java.lang.NoSuchMethodError).
Debugging my code I found that in the package org.apache.cocoon.forms
the following method is causing the problem:
public FormDefinition getFormDefinition(Source source) throws Exception
{
FormDefinition formDefinition =
(FormDefinition)this.cacheManager.get(source, PREFIX);
if (formDefinition == null) {
Document formDocument;
try {
InputSource inputSource = new InputSource(source.getInputStream());
inputSource.setSystemId(source.getURI());
formDocument = DomHelper.parse(inputSource, this.manager);
...
}
The offending line (better said the last that got processed is
formDocument = DomHelper.parse(inputSource, this.manager);
Does anybody have an idea what might be wrong?
I attached the diff for enabling cforms in lenya.
TIA for any thoughts.
salu2
thorsten
STACK
*****************************************************************
javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
org.apache.cocoon.ProcessingException: Calling function executeUsecase
at resource://org/apache/cocoon/forms/flow/javascript/Form.js:47:-1 at
file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/lenya/usecases/usecases.js:155:-1 at <map:call> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/lenya/usecases/usecase.xmap:71:46 at <map:mount> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/lenya/usecase.xmap:57:107 at <map:mount> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/global-sitemap.xmap:284:105 at <map:mount> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/sitemap.xmap:1330:110
cause: java.lang.NoSuchMethodError:
javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
org.apache.cocoon.ProcessingException: Calling function executeUsecase
at resource://org/apache/cocoon/forms/flow/javascript/Form.js:47:-1
at file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/lenya/usecases/usecases.js:155:-1
at <map:call> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/lenya/usecases/usecase.xmap:71:46
at <map:mount> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/lenya/usecase.xmap:57:107
at <map:mount> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/global-sitemap.xmap:284:105
at <map:mount> - file:/home/thorsten/apache/lenya-trunk/build/lenya/webapp/sitemap.xmap:1330:110
at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:134)
at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.getException(LocationTrackingDebugger.java:97)
at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:768)
at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:138)
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:250)
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.MatchNode.invoke(MatchNode.java:107)
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:250)
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:250)
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.ActTypeNode.invoke(ActTypeNode.java:138)
at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:102)
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:250)
at org.apache.cocoon.Cocoon.process(Cocoon.java:624)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1149)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)
Caused by: java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:199)
at org.apache.xalan.transformer.TransformerIdentityImpl.setDocumentLocator(TransformerIdentityImpl.java:880)
at org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe.java:39)
at org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe.java:39)
at org.apache.cocoon.util.location.LocatorToAttributesPipe.setDocumentLocator(LocatorToAttributesPipe.java:65)
at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:296)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)
at org.apache.cocoon.forms.util.DomHelper.parse(DomHelper.java:301)
at org.apache.cocoon.forms.DefaultFormManager.getFormDefinition(DefaultFormManager.java:155)
at org.apache.cocoon.forms.DefaultFormManager.createForm(DefaultFormManager.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1134)
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190)
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138)
at org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:766)
... 60 more
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Extending usecase-fw with cforms
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-08-19 at 11:17 +0200, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
>
> [...]
>
> > I am on vacation now and have some friends over here from Germany. I
> > will not be able to work on this till Monday night. If you are faster,
> > then be my guest. ;-)
>
> If your changes don't seem to affect existing functionality,
> I'd say you should check it in right now. I'd like to give it
> a try, but maybe I'll want to make modifications and I don't want to
> "steal your commit" :)
jeje
just apply the patch to your local checkout and enhance it (and give me
the credits in your commit message). ;-)
I am off now.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
[...]
> I am on vacation now and have some friends over here from Germany. I
> will not be able to work on this till Monday night. If you are faster,
> then be my guest. ;-)
If your changes don't seem to affect existing functionality,
I'd say you should check it in right now. I'd like to give it
a try, but maybe I'll want to make modifications and I don't want to
"steal your commit" :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-08-19 at 10:08 +0200, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
>
> > + /**
> > + * @return Returns the useCforms.
> > + */
> > + public boolean isUseCforms() {
> > + return useCforms;
> > + }
>
> I'd rather make this more general:
>
>
> <usecase ...>
> <view type="cforms">
> <cforms definition="..." binding="..."/>
> ...
> </view>
> </usecase>
>
>
>
> public static String VIEW_JX = "jx";
> public static String VIEW_CFORMS = "cforms";
> public static String VIEW_FOO = "foo";
>
> public int getViewType() {
> return this.viewType
> }
>
>
> Maybe we can use a ViewHandler class or something else
> to use polymorphism instead of static fields and an if/then/else
> condition in usecases.js?
>
Yes, makes sense. The patch was just a prototype implementation where I
did not wanted to change the architecture. A proof of concept. ;-)
> JavaScript is interpreted, so we can even create function
> calls dynamically.
>
Actually right now that is not necessary because we do not need a
different flow for cform then for jx.
>
> function cformsView(...) { ... }
> function jxView(...) { ... }
> function fooView(...) { ... }
>
That leads me to another extension of the usecase-fw: custom flow. With
the approach you recommend I see a way to enable custom flow scripts
into the usecase-fw. :) Good on ya, mate.
> ...
>
> eval(usecase.getViewType + "View(...)");
>
>
> That is IMO cleaner than if/then/else.
>
+1
I am on vacation now and have some friends over here from Germany. I
will not be able to work on this till Monday night. If you are faster,
then be my guest. ;-)
>
> -- Andreas
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-08-19 at 10:08 +0200, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
>
> > + /**
> > + * @return Returns the useCforms.
> > + */
> > + public boolean isUseCforms() {
> > + return useCforms;
> > + }
>
> I'd rather make this more general:
>
>
> <usecase ...>
> <view type="cforms">
> <cforms definition="..." binding="..."/>
> ...
> </view>
> </usecase>
>
>
>
> public static String VIEW_JX = "jx";
> public static String VIEW_CFORMS = "cforms";
> public static String VIEW_FOO = "foo";
>
> public int getViewType() {
> return this.viewType
> }
>
>
> Maybe we can use a ViewHandler class or something else
> to use polymorphism instead of static fields and an if/then/else
> condition in usecases.js?
>
> JavaScript is interpreted, so we can even create function
> calls dynamically.
>
>
> function cformsView(...) { ... }
> function jxView(...) { ... }
> function fooView(...) { ... }
>
> ...
>
> eval(usecase.getViewType + "View(...)");
>
>
> That is IMO cleaner than if/then/else.
Can you extend a wee bit on that?
I reckon that is the only suitable way.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
> + /**
> + * @return Returns the useCforms.
> + */
> + public boolean isUseCforms() {
> + return useCforms;
> + }
I'd rather make this more general:
<usecase ...>
<view type="cforms">
<cforms definition="..." binding="..."/>
...
</view>
</usecase>
public static String VIEW_JX = "jx";
public static String VIEW_CFORMS = "cforms";
public static String VIEW_FOO = "foo";
public int getViewType() {
return this.viewType
}
Maybe we can use a ViewHandler class or something else
to use polymorphism instead of static fields and an if/then/else
condition in usecases.js?
JavaScript is interpreted, so we can even create function
calls dynamically.
function cformsView(...) { ... }
function jxView(...) { ... }
function fooView(...) { ... }
...
eval(usecase.getViewType + "View(...)");
That is IMO cleaner than if/then/else.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-08-18 at 21:07 +0200, Thorsten Scherler wrote:
...
>
> > > cause: java.lang.NoSuchMethodError:
> > > javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
> >
> > mismatch between jaxp version and xalan version. you probably have xalan
> > 2.7 with an old (pre 1.3 JAXP) xml-apis.jar
cocoon-2.1.x/lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar
How can I found out which JAXP I am using?
> >
> > http://issues.apache.org/jira/browse/XALANJ-2158
>
> Hmm, thanks for the tip I will have a look. The only think is that I do
> not understand how that is happening.
>
> I am using
> cocoon-2.1.x
> lenya-1.4.x
> both on latest revision.
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
[...]
> i would be +1 to apply a cleaned up version of this patch, ideally
> together with some documentation.
+1
I'll be happy to take a look at it.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Thorsten Scherler <th...@wyona.com>.
On Tue, 2005-08-23 at 22:18 -0500, Antonio Gallardo wrote:
> Thorsten Scherler wrote:
>
> >I changed the the view definition a wee bit in the spirit of Andreas:
> >
> ><view template="usecases/test/cform.jx" type="cforms">
> > <definition template="usecases/test/cform.xml">
> > <before/>
> > <after>
> > form.setAttribute("counter", new java.lang.Integer(0));
> > </after>
> > </definition>
> > <binding template="usecases/test/cform_binding.xml">
> > <before>
> > var doc =
> >Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
> > doc.appendChild(doc.createElement("contracts"));
> > </before>
> > <after>
> > form.save(doc);
> > </after>
> > </binding>
> ></view>
> >
> >The before/after elements should get rid of the old code I mentioned in
> >the earlier message. So instead of using:
> > var doc =
> >Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
> > doc.appendChild(doc.createElement("contracts"));
> >in the usecase.js directly (that is limited to my special usecase) I
> >wanted to use:
> > view.getCformBindingBefore()
> >
> >That should allow custom flowscript additions that may be necessary for
> >the cforms. The problem is that "view.getCformBindingBefore()" is a
> >string that contains javascript commands which needs to be executed.
> >
> >I tried with eval( view.getCformBindingAfter()) but that gave:
> >"Calling eval() with anything other than a primitive string value will
> >simply return the value. Is this what you intended?"
> >
> >Does anybody know how to overcome that problem? For cforms we need to be
> >able to extend the usecase.js through custom flowscript.
> >
> >
> Maybe you are looking for:
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/forms/util/JavaScriptHelper.html
>
> A sample how to use it is here in the cforms binding code.
>
> 1. See how to build the load/save script (search for "/Build load
> script" or "//Build save script//"/):
>
> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/binding/JavaScriptJXPathBindingBuilder.java?view=markup
>
> 2. How to execute the script code (search for "doLoad(" or "doSave("):
>
> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/binding/JavaScriptJXPathBinding.java?view=markup
>
> I hope this helps, ;-)
>
> Best Regards,
Cheers Antonio.
No, sadly I just do not get it working this way either.
I need to do now other work, so I will not find time in the next
days. :(
Anyway should I commit the limited support for cforms? That means that
you cannot use custom flow extension for the cforms which is a PITA.
Anyway I talked to Antonio about this topic and he thinks that an
integration of custom flow and cforms would be best done via:
<!-- Flowscript Sample -->
<map:match pattern="form1.flow">
<map:call function="handleForm">
<map:parameter name="function" value="form1"/>
<map:parameter name="definitionURI" value="forms/form1.xml"/>
</map:call>
</map:match>
I will have a look on the weekend if I find time.
salu2
--
Thorsten Scherler
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Antonio Gallardo <ag...@agssa.net>.
Thorsten Scherler wrote:
>I changed the the view definition a wee bit in the spirit of Andreas:
>
><view template="usecases/test/cform.jx" type="cforms">
> <definition template="usecases/test/cform.xml">
> <before/>
> <after>
> form.setAttribute("counter", new java.lang.Integer(0));
> </after>
> </definition>
> <binding template="usecases/test/cform_binding.xml">
> <before>
> var doc =
>Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
> doc.appendChild(doc.createElement("contracts"));
> </before>
> <after>
> form.save(doc);
> </after>
> </binding>
></view>
>
>The before/after elements should get rid of the old code I mentioned in
>the earlier message. So instead of using:
> var doc =
>Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
> doc.appendChild(doc.createElement("contracts"));
>in the usecase.js directly (that is limited to my special usecase) I
>wanted to use:
> view.getCformBindingBefore()
>
>That should allow custom flowscript additions that may be necessary for
>the cforms. The problem is that "view.getCformBindingBefore()" is a
>string that contains javascript commands which needs to be executed.
>
>I tried with eval( view.getCformBindingAfter()) but that gave:
>"Calling eval() with anything other than a primitive string value will
>simply return the value. Is this what you intended?"
>
>Does anybody know how to overcome that problem? For cforms we need to be
>able to extend the usecase.js through custom flowscript.
>
>
Maybe you are looking for:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/forms/util/JavaScriptHelper.html
A sample how to use it is here in the cforms binding code.
1. See how to build the load/save script (search for "/Build load
script" or "//Build save script//"/):
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/binding/JavaScriptJXPathBindingBuilder.java?view=markup
2. How to execute the script code (search for "doLoad(" or "doSave("):
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/binding/JavaScriptJXPathBinding.java?view=markup
I hope this helps, ;-)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Thorsten Scherler <th...@apache.org>.
Hi again,
thx Gregor and Antonio, for pointing me to the xalan bug. That is
working for me. :)
I nearly finished the cform integration but I have one problem where I
can use some feedback.
On Thu, 2005-08-18 at 22:02 +0200, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
...
> >>> + //Fixme: use lenya doc
> >>> + var doc = Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
> >>> + doc.appendChild(doc.createElement("contracts"));
> >>> + form.createBinding(viewBind);
> >>> + form.save(doc);
> >> can you explain what the purpose of the contracts element is?
> >
> > That was my starting example (old code). It will have to be
> > configurable. That as well needs to be refactored.
>
I changed the the view definition a wee bit in the spirit of Andreas:
<view template="usecases/test/cform.jx" type="cforms">
<definition template="usecases/test/cform.xml">
<before/>
<after>
form.setAttribute("counter", new java.lang.Integer(0));
</after>
</definition>
<binding template="usecases/test/cform_binding.xml">
<before>
var doc =
Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
doc.appendChild(doc.createElement("contracts"));
</before>
<after>
form.save(doc);
</after>
</binding>
</view>
The before/after elements should get rid of the old code I mentioned in
the earlier message. So instead of using:
var doc =
Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
doc.appendChild(doc.createElement("contracts"));
in the usecase.js directly (that is limited to my special usecase) I
wanted to use:
view.getCformBindingBefore()
That should allow custom flowscript additions that may be necessary for
the cforms. The problem is that "view.getCformBindingBefore()" is a
string that contains javascript commands which needs to be executed.
I tried with eval( view.getCformBindingAfter()) but that gave:
"Calling eval() with anything other than a primitive string value will
simply return the value. Is this what you intended?"
Does anybody know how to overcome that problem? For cforms we need to be
able to extend the usecase.js through custom flowscript.
TIA for any thoughts or suggestions.
salu2
> i would be +1 to apply a cleaned up version of this patch, ideally
> together with some documentation. cforms integration is a common
> request, and there are some (now obsolete with this patch) instructions
> in the wiki that should be superseded by some notes in the vicinity of
> http://lenya.apache.org/1_4/reference/usecase-framework/index.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Thorsten Scherler wrote:
> Hmm, thanks for the tip I will have a look. The only think is that I do
> not understand how that is happening.
>
> I am using
> cocoon-2.1.x
> lenya-1.4.x
> both on latest revision.
>
> Anyway, another tip how I can fix that for us.
roll back to xalan 2.6.1 for now. if there are more problems, we might
have to pin lenya to 2.6.1 for the time being, even though 2.7 finally
works on jdk 1.5.
one really has to wonder why xalan never fails to cause problems with
new releases..
>>> + //Fixme: use lenya doc
>>> + var doc = Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
>>> + doc.appendChild(doc.createElement("contracts"));
>>> + form.createBinding(viewBind);
>>> + form.save(doc);
>> can you explain what the purpose of the contracts element is?
>
> That was my starting example (old code). It will have to be
> configurable. That as well needs to be refactored.
i would be +1 to apply a cleaned up version of this patch, ideally
together with some documentation. cforms integration is a common
request, and there are some (now obsolete with this patch) instructions
in the wiki that should be superseded by some notes in the vicinity of
http://lenya.apache.org/1_4/reference/usecase-framework/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-08-18 at 20:02 +0200, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
>
> > today I was trying to extend our usecase-fw with cforms. Everything was
> > looking great, because I could reuse all of the architecture and just
> > added some if/else clauses.
>
> looks good as far as i can tell, some comments below. much cleaner than
> the cforms integration in the sandbox.
>
:) cheers.
> > cause: java.lang.NoSuchMethodError:
> > javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
>
> mismatch between jaxp version and xalan version. you probably have xalan
> 2.7 with an old (pre 1.3 JAXP) xml-apis.jar
>
> http://issues.apache.org/jira/browse/XALANJ-2158
Hmm, thanks for the tip I will have a look. The only think is that I do
not understand how that is happening.
I am using
cocoon-2.1.x
lenya-1.4.x
both on latest revision.
Anyway, another tip how I can fix that for us.
>
> > + } catch (ConfigurationException e) {
> > + //do nothing
> > + }
>
> why?
The cform get invoked when
the @cformDefinition is in the view-conf part of the
usecase-{name}.xconf:
<view template="..." cformDefinition="..." />
I did not used:
config.getAttribute(ATTRIBUTE_CFORM_DEFINITION,null);
but
config.getAttribute(ATTRIBUTE_CFORM_DEFINITION);
which was throwing an exception about attribute not found when the
@cformDefinition was not set. The easiest thing was to catch the
exception and do nothing. ;-)
Anyway that will be gone as soon as I use
config.getAttribute(ATTRIBUTE_CFORM_DEFINITION,null);
Cheers for pointing that out.
>
> > + //Fixme: use lenya doc
> > + var doc = Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
> > + doc.appendChild(doc.createElement("contracts"));
> > + form.createBinding(viewBind);
> > + form.save(doc);
>
> can you explain what the purpose of the contracts element is?
That was my starting example (old code). It will have to be
configurable. That as well needs to be refactored.
Thanks very much Gregor for your help. :) I will look how to solve the
lib problem (...but you can always beat me to it). ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by Antonio Gallardo <ag...@agssa.net>.
Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
>
>> today I was trying to extend our usecase-fw with cforms. Everything was
>> looking great, because I could reuse all of the architecture and just
>> added some if/else clauses.
>
>
> looks good as far as i can tell, some comments below. much cleaner
> than the cforms integration in the sandbox.
>
>> cause: java.lang.NoSuchMethodError:
>> javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
>
>
> mismatch between jaxp version and xalan version. you probably have
> xalan 2.7 with an old (pre 1.3 JAXP) xml-apis.jar
>
> http://issues.apache.org/jira/browse/XALANJ-2158
Exactly. The error happens because xalan 2.6.1 uses DOM level 2 and
xalan 2.7.0 uses DOM level 3.
To be sure you are using the right versions of xalan and xerces, please
copy $COCOON_HOME/lib/endorsed to the java endorsed directory.
After coping the files, rebuild everything.
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Extending usecase-fw with cforms
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Thorsten Scherler wrote:
> today I was trying to extend our usecase-fw with cforms. Everything was
> looking great, because I could reuse all of the architecture and just
> added some if/else clauses.
looks good as far as i can tell, some comments below. much cleaner than
the cforms integration in the sandbox.
> cause: java.lang.NoSuchMethodError:
> javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
mismatch between jaxp version and xalan version. you probably have xalan
2.7 with an old (pre 1.3 JAXP) xml-apis.jar
http://issues.apache.org/jira/browse/XALANJ-2158
> + } catch (ConfigurationException e) {
> + //do nothing
> + }
why?
> + //Fixme: use lenya doc
> + var doc = Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
> + doc.appendChild(doc.createElement("contracts"));
> + form.createBinding(viewBind);
> + form.save(doc);
can you explain what the purpose of the contracts element is?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org