Hehe. I only learned enough to parse in my XHTML (which is just html with a
few / in the right places) and get a DOM (which is basically a glorified
tree with several types of nodes, and 90% of the time im just interested in
the element node type)). So if my xhtml has <input id="bob" type="text"
value="blah"/> I could use something like
document.getElementById("bob").setAttribute("value","yada yada yada");
(Actually I do a lot more and at an abstract level - but its still not very
technically complicated - the complexity is all stuff Ive added. For
example, if the bob element was a <td> or a <span> or a <textarea> etc... my
code is smart enough to figure it out and modify the DOM in an appropriate
manner, so I can fool around with the layout to a certain degree with no
code changes required).Still havent learnt all that xPath, and xslt stuff... now THAT looks hard ;-) -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 12:51 To: Struts Users Mailing List Subject: Re: Struts Vs. Sun J2EE Compliance and Design Patterns Andrew Hill wrote: >C arrays start at one! rofl! Which book was that! > I don't recall now. The dept chair was giving the computer club books to sell for funds at the time, and I think general consensus was that _that_ book should simply be burned - which we did, with great pleasure, while consuming large amounts of alcoholic beverages ;-) Ah - the joys of college. LOL >Yep. One can certainly do very good code in JSPs, and one can do very bad >code in Java, so in the end, as you say its up to the developer concerned. >Personally I find JSPs somewhat ugly, and I dont like having to wait till >deploytime or runtime to see if I made a stupid typo somewhere (I do this a >lot), and I find normal java source code a lot easier to debug when I get >exceptions or other such errors (which is also quite often!). I also didnt >have time to learn JSP in depth when I started this project and found it >quicker to develop using skills I already had (plain xhtml, and 'normal' >java). >Its really a matter of preference. > Yes, it really is :-) I'm in your reverse position though. I found it much easier to pick up JSP than XML. To this day, I have an XML aversion that I hope to eventually cure. >Ive implemented a simple caching mechanism, so I only have to parse the XML >into a DOM once for a particular page (XMLC, which is also DOM based, takes >another approach here and actually generates a java class file at compile >time with code that will assemble the DOM at runtime), but of course the DOM >still has to be written out as text at the end of the day. Im not sure how >much slower this is than straight print() calls in the compiled jsp code. >Shouldlnt be too bad I would think as its really just a case of the >XHTMLSerializer walking the tree, but obviously theres somewhat more >overhead there. I dont think the 2 second servlet folk would appreciate it >;-) > Ahhhhhh - you probably don't suffer as much as I thought you did. PFFFFFT! You know - some companies think they are "so bright". It's amazing to know that some of them are indoctorinating folks into such habits. ... sad really. >Off topic, but still talking xml, I gather most modern browsers now support >xml and xsl so you can return xml and have the stylesheet on your server >where the broswer will pull it up and do the conversion. Your presentation >code here would return xml and a neat opportunity this presents it that you >could supply different stylesheets for different locales, client devices, >etc... (For clients that cant do the conversion, you would do it for them of >course and then return the final *ml). Theres a library for doing this sort >of thing in struts (stxx I think its called?). Alas, I never had time to >look into this. Seems pretty cool though. > Love the concept - hate the XML ;-) No offense. As I said, I have an aversion to XML I need to overcome. I do see it's utility - lots of power. I just haven't had time to put forth brain-power actually trying to learn it well yet :-/ ... but I'm sure that day will come. Bed-time :-/ -- 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]>
