See also: xtags http://jakarta.apache.org/taglibs/doc/xtags-doc/intro.html
and open symphony transform tags: http://www.opensymphony.com/transformtags/ for examples of taglibs that transform xml against a given xsl. Lisa -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 14 May 2002 16:42 To: Struts Users Mailing List Subject: Re: new tag request <html:xslt> - was : xml-xslt v jsp Hmm.... Thought I was sooo smart. The JSTL already provides this.... http://jakarta.apache.org/taglibs/doc/xsl-doc/xsl-1.0/index.html FWIW - Kevin [EMAIL PROTECTED] on 05/14/2002 10:46:19 AM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: Re: new tag request <html:xslt> - was : xml-xslt v jsp Now that I look at this - I like this 3rd use case even better: 3. allow xml to be specified in-line. Tag then transforms against xsl specified by "xsl" attribute <html:xslt xsl="path_or_url/to/stylesheet.xsl" > // XML document then created dynamically based on // values from form-bean and other view objects. <myXMLDoc> <field 1> <%= bean1.getValue1() %> </field 1> <field 2> etc... </field 2> </myXMLDoc> </html:xsl> [EMAIL PROTECTED] on 05/14/2002 10:38:34 AM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: new tag request <html:xslt> - was : xml-xslt v jsp A more fundamental issue here is that this only really addresses the "view" of the MVC architecture. That is, XSL/XSLT/XPATH are really only useful once you have the data you are prepared to present (in the xml record) and want to render it into html (using XSL/XSLT). Given that, I believe that providing a method to allow xml/xsl/xslt to be used in a Struts View would be very useful. Maybe it would go something like this: new tag: <html:xslt > - perform xml/xsl transformation two use cases: 1. specify tag with xml and xsl attributes. The tag then performs a transform and returns results. e.g.: <html:xslt xml="path_or_url/to/input.xml" xsl ="path_or_url/to/stylesheet.xsl" /> oe, even better: 2. allow xsl to be specified in-line. Tag takes xml input from a path or url and transforms against the in-line xsl: <html:xslt xml="path_or_url/to/input.xml" > // allow xsl to be coded directly in-line </html:xsl> Any enterprising developers willing to add this? My plate is too full already.... FWIW - Kevin <[EMAIL PROTECTED]> on 05/14/2002 10:36:03 AM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: xml-xslt v jsp > isn't teaching a designer XSLT to modify a schema into > HTML easier than teaching them to not break your java > code inside of a jsp? > No, it's not. XSLT *is* a programming language and you have to know XPath to really do anything practical with XSLT. I would never try to teach designers XSLT (who define "programming" as doing cool stuff with DHTML) That is not to say that they are stupid. They have their own area of expertise in an area in which I cannot perform. XSLT is geared to a programmer's mindset. You have loops, conditionals, etc. If designers ever look at source code, they will recognize Java because it looks similar to JavaScript. If they're not proficient with it, they will leave it alone. XSLT will be a whole new world for them. Now, I would argue that if you have Java code in your JSP, you should try to get it out using tags. The cases when Java code is in the JSP should be rare. A well-designed tag library will be much easier to train designers to work around than XSLT. > i would much rather teach my designers simple > transformations than worry constantly about whether they > ate my tags containing my java code. > Simple transformations are few and far between in my experience. XSLT is a great language. But it is not simple, not nearly as simple as a well-designed JSP tag, IMHO. > where are ya'll doing the transformations - server or > client side? > I've done both. It's been a year or so, but server-side transformations were dogs for performance. Client-side works fine, but you have to be able to control the browser. For IE, you have to make sure the user has the right version of MSXML installed. For Netscape, can Netscape do XSLT at all? Seems like version 6 can, but I don't know. Bottom line. If you use XSLT you will have to address performance issues. Greg -- To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED]> For additional commands, e-mail: < mailto:[EMAIL PROTECTED]> --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --------------------------------------------------------------------------- -- To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED]> For additional commands, e-mail: < mailto:[EMAIL PROTECTED]> --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --------------------------------------------------------------------------- -- To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED]> For additional commands, e-mail: < mailto:[EMAIL PROTECTED]> --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --------------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
