Re: XMLForm Xindice howto at Wiki refactored and ready

2003-02-01 Thread Josema Alonso 
> 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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XMLForm Xindice howto at Wiki refactored and ready

2003-02-01 Thread Ivelin Ivanov 

-=Ivelin=-
- Original Message -
From: "Josema Alonso" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
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: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XMLForm Xindice howto at Wiki refactored and ready

2003-01-31 Thread Josema Alonso 
> 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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XMLForm Xindice howto at Wiki refactored and ready

2003-01-31 Thread Ivelin Ivanov 

> 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.
> >  
> >
> > 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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XMLForm Xindice howto at Wiki refactored and ready

2003-01-31 Thread Josema Alonso 
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.
>
>  
>   Artist identifier:
> 
> 
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.
>  
>
> 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.tre

Re: XMLForm Xindice howto at Wiki refactored and ready

2003-01-31 Thread Ivelin Ivanov 
Josema,

The new revision is excelent.

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 would recommend the following minor corrections to the code:

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.

 
  Artist identifier:



same applies for

String artistName = (String)getForm().getValue(//@id);
...
v.setPath(//@id);


Do you even need // for
Node result = xi.find(xindiceSubCol, "//Artist[@id='"+ artistName +"']",
"Artist");

this looks like stale code

  //v.setPath("/artistName");



You can remove the reset() method.
Checkboxes are automatically handled for session scope beans.
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.




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.
 

If you think this makes sense, please consider submitting a patch to that
effect.



Congratulations for the great job once again.


-=Ivelin=-
- Original Message -
From: "Josema Alonso" <[EMAIL PROTECTED]>
To: "Cocoon-Users" <[EMAIL PROTECTED]>
Sent: Tuesday, January 28, 2003 1:06 PM
Subject: XMLForm Xindice howto at Wiki refactored and ready


> Ivelin and all,
>
> I finally had the time to refactor the example. Following the ideas we
> exchanged these past days, I put it altogether at Wiki and I think we have
> now a much better sample :-)
> http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice
>
> Please, review it if you want to and inform me of any faults you can find
so
> i could fix them. I hope i wrote a clear explanation.
>
> If you feel this can be a good addittion to the official how-tos feel free
> of adding it yourself of let me know who I should contact (Diana, maybe?)
or
> where I should start. I still have not contributed anything to the
official
> docs and I'm somewhat lost...
>
> Thanks.
>
>
>
> -
> 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: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
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: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

XMLForm Xindice howto at Wiki refactored and ready

2003-01-28 Thread Josema Alonso 
Ivelin and all,

I finally had the time to refactor the example. Following the ideas we
exchanged these past days, I put it altogether at Wiki and I think we have
now a much better sample :-)
http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice

Please, review it if you want to and inform me of any faults you can find so
i could fix them. I hope i wrote a clear explanation.

If you feel this can be a good addittion to the official how-tos feel free
of adding it yourself of let me know who I should contact (Diana, maybe?) or
where I should start. I still have not contributed anything to the official
docs and I'm somewhat lost...

Thanks.



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>