DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36643>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36643 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-17 17:07 ------- (In reply to comment #4) > (In reply to comment #3) > There is one big difference. For JSP, the implicit meaning is part of the > spec and every developer should know it. If the developer does not know what > he does, he must learn it on the hard way. > For HTML, no such implicit behaviour exist and therefore the designers are > possibly not aware of the restriction. And to make things worse, the tools > they use are not aware of the restriction too. So it is possible that every > time you save your file, you have to change it back manually to character > references. I see what you me. From a similar front, we have tried very hard with our html parser to not impose a standard on the templates. I had thought this would be a good feature for developers that wanted to travel lite and fast without the need of an XML configuration file. There's allot of fuss now about verbose configuration files. In not all cases is a developer going to have a web designer to build the mockup's. It's hard to argue that there is much of a difference between (1) and something very similar (2). 1) <title>#{msgs['usecases.rolodex2']}</title> 2) <title><span jsfid="outputText" value="#{messages['usecases.rolodex2']}" allowBody="false">Mock Title</span></title> If I was traveling fast and lite, I would prefer the first. I would also argue that if a web designer had to enter #{ something } within a document token, they should know enough about the technology to escape the special characters as they would have to know to escape these characters <>. I think our efforts would be better focused on building a tool from our existing parser to rip through documents before staging. I think it would be handy to be able to rip a JSP page into a clay template. Or, maybe build a tool to handle the case you have described. Or, extend clays html builder to handle creating faces components from struts jsp tags as a migration option. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
