OK, so I can settle (grudgingly) for writing/finding another XML tag library that can actually manipulate XML. The shame of it is that if I want to also use the JSTL tags (which I like very much) then I'll have to duplicate all of my XPath expressions and context variables for the new tags because the only JSTL tag that exposes a standard w3c.dom.Document is <x:parse>. If only <x:set> and <x:forEach> had a "varDom" attribute, then the JSTL could be easily complemented by other (naughty) XML-based tag libraries.
When an XPath expression is evaluated, the result is mapped to a Java type according to the following rules:
XPath Java
----- ----
boolean -> java.lang.Boolean
number -> java.lang.Number
string -> java.lang.String
node-set -> Type usable by JSTL XML-manipulation
tags in the same JSTL implementation. The
specific Java type representing node-sets
may thus vary by implementation.If I understand you correctly, given that the only mapping that's not specified is 'node-set', you'd want the capability to force the mapping of an XPath node-set to be of a specific type, e.g. org.w3c.dom.NodeList. Correct?
-- Pierre
Murray Lang wrote:
Are you saying that if I want to get user input (from a <form>) into XML for a back-end system then JSP is not suitable?. I can't accept that.
I could use Struts (which seems like overkill), or write a tag library that took all of the <form> values and spat out w3c.dom.Document, but any changes to the input options would then require that a bean and its JAR be recompiled and re-deployed. Using a generic XML Tag library to put the values into an XML tree would be more maintainable.
OK, so I can settle (grudgingly) for writing/finding another XML tag library that can actually manipulate XML. The shame of it is that if I want to also use the JSTL tags (which I like very much) then I'll have to duplicate all of my XPath expressions and context variables for the new tags because the only JSTL tag that exposes a standard w3c.dom.Document is <x:parse>. If only <x:set> and <x:forEach> had a "varDom" attribute, then the JSTL could be easily complemented by other (naughty) XML-based tag libraries.
Murray
At 04:24 PM 7/05/2004, you wrote:
hey, come on, this is just a jsp - you would not really want to litter your presentation layer with all sorts of business-logic: if jstl goes down this path, it will end up being a crippled version of cfml or even worse asp...
Murray Lang wrote:
Actually, what the Sun JSTL web page says is:
"JSTL has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and SQL tags."
"manipulating"!
Anyway, I take your point that it is outside the scope of the JSTL XML tags at the moment. It seems to me a rather arbitrary limitation though. As the JSTL documentation says: "...when companies cooperate over the web, XML is the data format of choice for exchanging information.". IMHO being unable to manipulate XML is odd for a technology that has such language in it's documentation. An exchange of information involves two parties, one at least of which has created some XML.
Thanks for the JXPath link. What worries me about it though is that it won't necessarily use the same DOM implementation as JSTL implementation, meaning that they won't work with each other. It seems a shame if this is the case. I'll look at it though - it might not be that bad.
Cheers
Murray
At 01:33 AM 7/05/2004, you wrote:
This is outside the scope of the taglibrary, JSTL xml taglibrary is for presentation of xml content, not for its manipulation. I recommend looking into a package such as JXPath to accomplish manipulation of the content of a DOM object. the nice thing is that JXPath can be scripted into a JSP, Servlet or Struts Action, which gives you the fredom to move it out of the Presentation layer (where you probibly shouldn't be placing such logic).
http://jakarta.apache.org/commons/jxpath/
Good Luck -Mark
Murray Lang wrote:
Hi
I've been using the XML tags in JSTL and found them very useful, however now I need to add an attribute to an XML element and have hit a brick wall.
I've tried using <c:set> and EL, treating a DOM object as a bean, but the DOM interface is implementation-dependent and my implementation (xerces) doesn't lend itself to adding attributes with the simple EL view of bean properties.
It seems to me that <x:set> needs to have a "target"attribute along the same lines as <c:set>, but accepting an XPath expression.
eg
<x:set select="12345" target="$myRoot//myElement[position()=0]/@myAttribute" />
where:
- select can be either an XPath expression or an immediate value.
- if @myAttribute doesn't currently exist in the element then it is created.
Does this make sense?
Is there a simple, portable, way of achieving this using JSTL as it stands? (Using <c:set> is not portable due to DOM being implementation dependent).
Thanks Murray
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stefan Frank iBioS - Intelligent BioInformatics Systems http://www.dkfz-heidelberg.de/ibios DKFZ - German Cancer Research Center Im Neuenheimer Feld 580 69120 Heidelberg Tel.: +49 (0) 6221 42-3612 Mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
