For example:
<x:set target="$myXML/myElement/@myAttribute" select="SomeValue" />
Never mind. The fact is that I can't do this and my JSP was getting messy enough anyway without putting in extra workarounds to modify my XML data.
I'm going to bite the bullet now and try Struts (I tried XForms but it was a waste of time due to limits in the implementations).
Murray
At 10:28 AM 13/05/2004, you wrote:
Thanks Pierre,
Where I don't follow is when you say that "any changes to the input options would then require that a bean and its JAR be recompiled and re-deployed."
Firstly I should point out that I am working on a prototype ("hacking" might be a little more honest), to try to clarify in my own head and in the head of my client how the application will look.
My understanding of Struts (I haven't used it yet but I'm thinking maybe I should) is that a form needs a corresponding "ActionForm" bean, with fields corresponding to the form elements. So if the form changes then the bean must change. If I was to write a custom tag (also a bean) to create the XML from the form values then the tag library might also need rebuilding with changes to form contents. I know this makes me sound lazy and such a scenario isn't really that bad, but if only JSTL could manipulate XML then the job could be done with a single line of JSP (per value).
Could you provide more specific details on your use-case?
- A system that performs hydrodynamics calculations accepts its numerous input parameters in XML. The program is a work in progress and the parameters will be refined and enhanced over time.
- Previously performed calculations (parameters and results) can be retrieved from the system in XML.
- The system is accessed in JSP through a tag library.
- The JSP form for inputting the parameters can be initialised with values from a previous calculation. The JSTL XML tag library is used for this.
- Values from the form need to go into the same XML format to pass to the system's tag library for calculation/storage.
So the DOM object is sitting there as a context variable and I've got all of the parameters singled out - but I can't put new values back in. I have to go through the rigmorol of creating a new DOM tree with the parameters. Note also that to refresh the form with the new XML means that it will have to replace the original DOM context variable. Seems wasteful to me.
XForms is another approach I'm looking at, but all of these technologies take time to master and, as much as I'd love to, I can't spend forever messing around with them.
Murray
At 05:17 AM 13/05/2004, you wrote:Murray,
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.
I'm always interested in hearing more about XML-related use cases.
If I understand you well, you want a JSP page (that is the target of a form submission) to create an XML document out of all the request parameters it receives. Correct?
Where I don't follow is when you say that "any changes to the input options would then require that a bean and its JAR be recompiled and re-deployed."
Could you provide more specific details on your use-case? I'd like to dig a little more and see how best your use-case should be handled (given the constraints of your environment). This thread has already generated some great feedback from Mark and Kris, and I'm sure we can milk even more interesting comments from it...
-- 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]
--------------------------------------------------------------------- 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]
