You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Josema Alonso <jo...@josema.net> on 2003/02/01 01:43:39 UTC
Re: XMLForm Xindice howto at Wiki refactored and ready
Hello again, Ivelin.
> The new revision is excelent.
Thank you very much.
> Please follow the instructions to submit an official HOWTO
> http://xml.apache.org/cocoon/howto/howto-author-howto.html
>
> Diana will take it from there.
I'll do once solved the doubts below. Thanks.
> In the fragment below, why use "//". Is it a typo?
> "/info" and "/@id are probably more appropriate.
> The ref in the textbox case should always resolve to a single node. "//"
may
> return a nodeset.
>
> <xf:textbox ref="//@id">
> <xf:caption>Artist identifier:</xf:caption>
> </xf:textbox>
> <xf:textbox ref="//Name">
I see, but let me explain it.
I should not use "//", that's ok, but I think "/@id" for example is not
enough.
If I'm right, using "/" gives the Document Root but not the Root Element and
I can't access from there the id attribute. Also, making it that way I get
the exception at the end of this message, which seems to confirm my theory.
So, what I think it could be a good solution is to use '/Artist/@id' and
'Artist/Name'. What do you think? Am I wrong?
> same applies for
>
> String artistName = (String)getForm().getValue(//@id);
> ...
> v.setPath(//@id);
Same observations as above can be applied here.
> Do you even need // for
> Node result = xi.find(xindiceSubCol, "//Artist[@id='"+ artistName +"']",
> "Artist");
Nope, don't need it here. I'm changing this asap.
> this looks like stale code
>
> //v.setPath("/artistName");
It is. Thank you.
> You can remove the reset() method.
> Checkboxes are automatically handled for session scope beans.
I see. Thank you.
> My experience shows that when representing plain value objects, session
> beans are never a memory concern
> with the modern app servers.
> I would prefer them almost always over request scope.
> Much easier to code, which results in less code and less maintanance.
I'm with you on this. I'm using session beans in my web apps. I always try
not to heavy load the session but some data in there doesn't hurt at all and
makes life much easier.
> On a different note, I thinkg that your code can be used in the
> AbstractXMLFormAction.
>
> For example when the map parameter is prefixed with "java:", like in
> "java:org.my.TestBean",
> then the existing JavaBean instantiation logic can be used.
> In all other cases, the model can be resolved via the SourceResolver.
> This will allow benefiting from the InputModules to access xml files from
> different sources: file system, xindice, remote URL, etc.
> <map:parameter name="xmlform-model" value="artist/artist-model.xml"/>
>
> If you think this makes sense, please consider submitting a patch to that
> effect.
I like very much this approach. Unfortunately I do not think I'm expert
enough to accomplish this yet and I do not want to touch things that are
working. I'm afraid I could make some mistakes.
I also should learn more about Input Modules, I still haven't used them at
all.
Anyway, if nobody's doing it, I should try it sooner or later...it would be
a good addition.
> Congratulations for the great job once again.
Thank you very much again, too :-)
----------------------------------------------
ERROR TRACE WHEN USING '/@id':
type fatal
message Cannot setValue of an object that is not some other object's
property/child
description java.lang.UnsupportedOperationException: Cannot setValue of an
object that is not some other object's property/child
sender org.apache.cocoon.servlet.CocoonServlet
source Cocoon servlet
request-uri
/cocoon/xmtrader/xmldb/xforms/Artist.xform
path-info
xmtrader/xmldb/xforms/Artist.xform
stack-trace
java.lang.UnsupportedOperationException: Cannot setValue of an object that
is not some other object's property/child
at
org.apache.commons.jxpath.ri.model.beans.NullPointer.setValue(NullPointer.ja
va:110)
at org.apache.cocoon.components.xmlform.Form.setValue(Form.java:273)
at org.apache.cocoon.components.xmlform.Form.populate(Form.java:436)
at
org.apache.cocoon.acting.AbstractXMLFormAction.act(AbstractXMLFormAction.jav
a:287)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTyp
eNode.java:139)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:85)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:166)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:153)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:143)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:326)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:308)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
e.java:131)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:85)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:166)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:153)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:143)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:326)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:308)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
e.java:131)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:85)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:166)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:153)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:143)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:326)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:308)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
e.java:131)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:85)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:166)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:153)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:109)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:143)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:326)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:308)
at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1034)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2350)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:171
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:469)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
1040)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1151
)
at java.lang.Thread.run(Thread.java:536)
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: XMLForm Xindice howto at Wiki refactored and ready
Posted by Josema Alonso <jo...@simbiosystems.com>.
> Please modify it to /Artist/@id, do not leave it as //
That's what I meant. Sorry if I didn't write it clearly.
Best.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: XMLForm Xindice howto at Wiki refactored and ready
Posted by Ivelin Ivanov <iv...@apache.org>.
-=Ivelin=-
----- Original Message -----
From: "Josema Alonso" <jo...@simbiosystems.com>
To: <co...@xml.apache.org>
Sent: Friday, January 31, 2003 11:06 PM
Subject: Re: XMLForm Xindice howto at Wiki refactored and ready
> > I think you are correct.
> > The point is to identify the exact xpath to the @id attribute.
> Ok, so I let it that way then.
Please modify it to /Artist/@id, do not leave it as //
>
> > If you get it started, I can review the changes and we should be able to
> > wrap it up in a few iterations.
> Well, first I'll see what to do regarding the howto. I mean, I'll read the
> howto submit a howto and all and get it touch with Dianna and make it
> available in the docs...
> After that I'll try to learn something about Input Modules. And then maybe
> I'll take the challenge and try to make it. I'll drop you a line then.
>
> Best.
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: XMLForm Xindice howto at Wiki refactored and ready
Posted by Josema Alonso <jo...@simbiosystems.com>.
> I think you are correct.
> The point is to identify the exact xpath to the @id attribute.
Ok, so I let it that way then.
> If you get it started, I can review the changes and we should be able to
> wrap it up in a few iterations.
Well, first I'll see what to do regarding the howto. I mean, I'll read the
howto submit a howto and all and get it touch with Dianna and make it
available in the docs...
After that I'll try to learn something about Input Modules. And then maybe
I'll take the challenge and try to make it. I'll drop you a line then.
Best.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: XMLForm Xindice howto at Wiki refactored and ready
Posted by Ivelin Ivanov <iv...@apache.org>.
> I see, but let me explain it.
> I should not use "//", that's ok, but I think "/@id" for example is not
> enough.
> If I'm right, using "/" gives the Document Root but not the Root Element
and
> I can't access from there the id attribute. Also, making it that way I get
> the exception at the end of this message, which seems to confirm my
theory.
>
> So, what I think it could be a good solution is to use '/Artist/@id' and
> 'Artist/Name'. What do you think? Am I wrong?
I think you are correct.
The point is to identify the exact xpath to the @id attribute.
> > This will allow benefiting from the InputModules to access xml files
from
> > different sources: file system, xindice, remote URL, etc.
> > <map:parameter name="xmlform-model" value="artist/artist-model.xml"/>
> >
> > If you think this makes sense, please consider submitting a patch to
that
> > effect.
> I like very much this approach. Unfortunately I do not think I'm expert
> enough to accomplish this yet and I do not want to touch things that are
> working. I'm afraid I could make some mistakes.
> I also should learn more about Input Modules, I still haven't used them at
> all.
> Anyway, if nobody's doing it, I should try it sooner or later...it would
be
> a good addition.
If you get it started, I can review the changes and we should be able to
wrap it up in a few iterations.
Ivelin
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>