That's a good point, but what about when your scriptlets are controlling the presentation? Ie. you've got dynamic row changes, or entirely different tables of output being displayed depending on a flag on the request (assuming you can't generecize the output) - and the designer needs to change the HTML output by those scriptlets? Frankly, I don't mean to diminish the role of the designer (someone I find to be incredibly important) but I generally would not let them edit JSP's at all taglibs or not, unless they had experience with JSP or ASP. While it may not be ideal or efficient to do so, I find that it is much better for the designers to provide me with a mockup and I'll deal with the HTML. It gives developers much more control and flexibility - and then all these issues are moot. Plus, it gives you the added bonus of avoiding the demons that are WYSIWYG web development tools (hehe, I'm known lovingly as the "HTML snob" by one of my uncles who happens to be a designer). Unfortunately, not every developer knows HTML well so it involves more responsibility for the developer then may actually be good, possible or practical, but for me personally, I wouldn't have it any other way. :) -Chris -----Original Message----- From: Greg Maletic [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 01, 2001 1:15 PM To: [EMAIL PROTECTED] Subject: Taglibs decrease the separation between designer and developer? Your post brings up a good point concerning what I think is a false assumption concerning the separation between designer and developer. Despite the potential good uses that taglibs can be put to, HTML pages with JSP scriptlets are, I believe, easier to read by web designers than pages with Struts taglibs. (The one caveat being the one I mentioned before--that ONLY view logic--and not business logic--should reside in scriptlets.) My reasoning--and experience--is that when I simply used JSPs, I told our designer to completely ignore the stuff inside the "<% %>"s and code around them. Things were fine. Now that we're using Struts, I have to instruct our designer on the ins and outs of a completely new set of pseudo-HTML tags that he doesn't understand at all--and NOT to use the tags he's familiar with ("<form>", "<head>", etc.) It was much easier for both him and me before we made this switch. Struts taglibs--and other taglibs--introduce, in essence, yet another language that we all have to learn. ====================================== Greg Maletic Chief Technical Officer Zero G Software, Inc. 514 Bryant Street San Francisco, CA 94107 tel: +1.415.512.7771 x303 fax: +1.415.723.7244 mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> http://www.ZeroG.com <http://www.ZeroG.com> The leading provider of multi-platform software deployment solutions. ====================================== -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg]On Behalf Of Tim Colson Sent: Tuesday, July 31, 2001 7:57 AM To: [EMAIL PROTECTED] Subject: HTML in Taglibs (was: some comparision between JSP/struts & velocity) Niall wrote: > Sorry, I couldnt disagree with you more. > Custom tags are exactly the place to put html - they are part of the view, Heh heh... I never said definitively that they weren't, just that in the particular situation we had - it seemed like a bad idea. The bits in question were definitively Designer territory. BTW - you are correct when saying this was/is part of the View. However, part of the separation I'm striving for is between Designer and Developer roles. And I hope you'll agree with me that a TagLib isn't something a Designer would likely build. <grin> > if you look at struts html tags thats what they do. Yes. I understand. And honestly, it makes me a trifle uneasy. ;-) Real example - I had a Designer chap get stumped because the html:form attribute "name" didn't actually map directly to the "name" of the "real html form". When he tried to connect a javascript function to an element in the form - he didn't know the name of the form. When he reasoned, "oh, I'll just name my html:form 'bleckfoo', just like I would if it was standard HTML... <html:form name="bleckfoo"... He got a lovely error similar to the following: > Error Location: Edit.jsp Internal Servlet Error: > javax.servlet.ServletException: Must specify type attribute if name is specified > at org.apache.jasper.runtime.PageContextImpl.handlePageException > (PageContextImpl.java:459) > at jsp._0002fjsp_0002fEdit_0002ejspEdit_jsp_2._jspService > (_0002fjsp_0002fEdit_0002ejspEdit_jsp_2.java:344) (That was a fun one to explain - lemme tell ya. <grin> ;-) My point - hiding complexity won't always make things simpler. To my Designer colleague, the fact that the <html:form automagically associates a Form bean with the form elements, as well as doing other nifty things for him/her behind the scenes didn't matter. What mattered was that they knew how to do HTML, and they were stumped about how to make this "Struts thingy" work. To which I have to reassure him that "Struts" is a good thing - it's the darn JSP's that are a bit cumbersome. ;-) Cheers, Tim
