Hey, if its all in the name of presentation, then who am I to argue.

But there is a conceptual dfiference your overlooking here. There is a big difference between taking a DOM and doing an xslt transform to produce new output vs. physically altering the original DOM object, The former is a "readonly" process, and the later is a "write" process. What if that DOM was actually implemented over some persistent source, now your using your presentation layer to do buisness logic...

Granted, JSTL already "bleeds" over the boundaries of "read/write" with the sql tags, and its rather difficult to define a boundary for objects acted on by the "c:set" tag as well.

-Mark

Kris Schneider wrote:

It's perfectly valid to perform those tasks for the sake of presentation logic.
Just because I'm manipulating an XML document doesn't mean that I'm performing
business logic. Does transforming your XML data to (X)HTML qualify as business
logic? As another example, an article by Bob DuCharme for XML.com
(http://www.xml.com/pub/a/2004/04/07/tr.html) outlines how to use XSLT to add
an id attribute to all elements, or to just a specific list of elements. This
may have nothing to do with business logic but it's quite useful for creating
links within an XHTML document. In fact, that article hits very close to a
solution for the original question...

Quoting Stefan Frank <[EMAIL PROTECTED]>:



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


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

Reply via email to