Re: [VOTE] How to implement XHMTL support
I'm still unclear on the direction we should take here. I'd like to hear from other committers :-). Thanks, Dave From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] How to implement XHMTL support Date: Tue, 12 Nov 2002 16:57:07 -0800 (PST) We need to ensure that HTML taglib tags in included JSP pages also heed the xhtml attribute. That isn't the case with what's there now, because findAncestorWithClass() will fail for the tags in the included pages. Note that this is why the form tag stores itself in a request attribute. Originally, it also used findAncestorWithClass(), but it was changed to allow forms to span pages. So I see two ways of handling this: A) Have the html:html tag store itself in a request attribute, and change BaseHandlerTag.isXhtml() to grab the tag from there before calling getXhtml(). B) Have the html:html tag store the value of its 'xhtml' attribute as a request attribute, and use that in BaseHandlerTag.isXhtml(). Of these, I prefer the first approach because it makes it harder for people to futz (technical term :) with the value in their pages. -- Martin Cooper On Tue, 12 Nov 2002, David Graham wrote: I've updated that html taglib tags to output xhtml when they are nested in a html:html xhtml=true tag. This was very simple to do and resulted in minor code changes. Users have suggested this approach: 1. Add Globals.XHTML_KEY which is a boolean request scoped attribute 2. html tags check for that request attribute being true and output accordingly. 3. The html:html tag sets this request attribute when it's xhtml attribute is true. The second approach allows the tags to output xhtml without relying on the html:html tag. This allows people to construct pages with jsp includes. The first approach is logically clearer (to me) and you can use tiles to modularly construct the pages like includes. Approach 2 may be confusing because you would have to remember all the places you may have set that request attribute. So, do we go with 1, 2 or both? David _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
I agree with Martin that you can't ignore people using jsp:include. I prefer his option B because then it allows someone to use the xhtml support in the other tags without forcing them to use html:html. They would have to set the attribute themselves and assume the risks that go along with making assumptions about how the tag is working. -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Wednesday, November 13, 2002 9:51 AM To: [EMAIL PROTECTED] Subject: Re: [VOTE] How to implement XHMTL support I'm still unclear on the direction we should take here. I'd like to hear from other committers :-). Thanks, Dave From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] How to implement XHMTL support Date: Tue, 12 Nov 2002 16:57:07 -0800 (PST) We need to ensure that HTML taglib tags in included JSP pages also heed the xhtml attribute. That isn't the case with what's there now, because findAncestorWithClass() will fail for the tags in the included pages. Note that this is why the form tag stores itself in a request attribute. Originally, it also used findAncestorWithClass(), but it was changed to allow forms to span pages. So I see two ways of handling this: A) Have the html:html tag store itself in a request attribute, and change BaseHandlerTag.isXhtml() to grab the tag from there before calling getXhtml(). B) Have the html:html tag store the value of its 'xhtml' attribute as a request attribute, and use that in BaseHandlerTag.isXhtml(). Of these, I prefer the first approach because it makes it harder for people to futz (technical term :) with the value in their pages. -- Martin Cooper On Tue, 12 Nov 2002, David Graham wrote: I've updated that html taglib tags to output xhtml when they are nested in a html:html xhtml=true tag. This was very simple to do and resulted in minor code changes. Users have suggested this approach: 1. Add Globals.XHTML_KEY which is a boolean request scoped attribute 2. html tags check for that request attribute being true and output accordingly. 3. The html:html tag sets this request attribute when it's xhtml attribute is true. The second approach allows the tags to output xhtml without relying on the html:html tag. This allows people to construct pages with jsp includes. The first approach is logically clearer (to me) and you can use tiles to modularly construct the pages like includes. Approach 2 may be confusing because you would have to remember all the places you may have set that request attribute. So, do we go with 1, 2 or both? David _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How to implement XHMTL support
whisperDon't bother drawing a ballot up - these guys don't use it! They're all like thinking outside the box and adding options to it, dude! ... and there's that one fellow who is always saying put your code where your mouth is - we only vote on code - while standing there with a wild, Clint Eastwood look on his face! (Go ahead punk - make my release-candidate!) In any case, most people will tell you to ask for forgiveness instead of permission./whisper I would follow Martin's suggest course of action, plan A. This way, you wind up having access to the tag, which is the Information Expert here. I don't agree with Martin's suggestion that this is a more robust way to handle things - I just think it's sensless to create things you don't need to. It's irrelevant whether you put a Boolean or the tag-handler out there with respect to the mucking of variables - the tag-handler is a java-bean, right? Thus, it could easily be updated at any stage too (ie futzed with). I do think it would be more efficient (albeit ever-so slightly) to just use the tag, since there is no additional creation of a Boolean object to stuff into the request. In either case, yes, you're going to want to add some key to Globals - the name of it I wouldn't hazard a guess at. What you have sounds ok, but it's really representing the tag now, so perhaps it should reflect that in it's name? (ok, fine, I will hazard a pseudo-guess at it! ;-) David Graham wrote: I'm still unclear on the direction we should take here. I'd like to hear from other committers :-). Thanks, Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
-Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] The presumption of storing the outer xhtml setting (independent of *how* you do so) is to let the included page automatically adapt to the outer page's choice - presumably, that lets you use the same included page in an XHTML and non-XHTML environment with no changes. But, in reality, that's only true if 100% of the content of the included page is struts-html tags -- if the developer has any static HTML elements, for example, they *must* have selected one style or the other, and that style won't get affected. You're going to end up with a mishmash. This is my primary objection to passing the xhtml flag through the jsp:include unconditionally. The included page needs to have control over this. Maybe what we really need is a way for the included page to tell its own Struts tags whether or not to be XHTML formatted or not. Perhaps a specialized version of html:html xhtml=... that was searched for the same way that the standard version is, but does *not* actually emit an html element? I don't think it would be a variation of the html:html element, it would have to be a separate tag, whose only purpose (AFAICS) is to set this flag. Would anyone have a reason to specify that the page should NOT use xhtml? I could envision a html:useXhtml tag (bleah), but should it have an attribute that specifies a true or false value, or can it be attribute-less? -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
What if we did this: 1. Store a boolean in the request under Globals.XHTML_KEY 2. html:html xhtml=true would set the boolean to true 3. html:xhtml (new tag) would set the boolean to true 4. People could manually set the request attribute if they choose and realize potential problems. This frees you from using html:html, and allows included jsps to set their xhtml status independently of the outer page. Does this accomodate everyone's needs? David From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 09:29:21 -0800 -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] The presumption of storing the outer xhtml setting (independent of *how* you do so) is to let the included page automatically adapt to the outer page's choice - presumably, that lets you use the same included page in an XHTML and non-XHTML environment with no changes. But, in reality, that's only true if 100% of the content of the included page is struts-html tags -- if the developer has any static HTML elements, for example, they *must* have selected one style or the other, and that style won't get affected. You're going to end up with a mishmash. This is my primary objection to passing the xhtml flag through the jsp:include unconditionally. The included page needs to have control over this. Maybe what we really need is a way for the included page to tell its own Struts tags whether or not to be XHTML formatted or not. Perhaps a specialized version of html:html xhtml=... that was searched for the same way that the standard version is, but does *not* actually emit an html element? I don't think it would be a variation of the html:html element, it would have to be a separate tag, whose only purpose (AFAICS) is to set this flag. Would anyone have a reason to specify that the page should NOT use xhtml? I could envision a html:useXhtml tag (bleah), but should it have an attribute that specifies a true or false value, or can it be attribute-less? -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
Forgot this: 5. Tags nested in html:html xhtml=false will not be rendered in xhtml regardless of any other settings. Dave From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:41:53 -0700 What if we did this: 1. Store a boolean in the request under Globals.XHTML_KEY 2. html:html xhtml=true would set the boolean to true 3. html:xhtml (new tag) would set the boolean to true 4. People could manually set the request attribute if they choose and realize potential problems. This frees you from using html:html, and allows included jsps to set their xhtml status independently of the outer page. Does this accomodate everyone's needs? David From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 09:29:21 -0800 -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] The presumption of storing the outer xhtml setting (independent of *how* you do so) is to let the included page automatically adapt to the outer page's choice - presumably, that lets you use the same included page in an XHTML and non-XHTML environment with no changes. But, in reality, that's only true if 100% of the content of the included page is struts-html tags -- if the developer has any static HTML elements, for example, they *must* have selected one style or the other, and that style won't get affected. You're going to end up with a mishmash. This is my primary objection to passing the xhtml flag through the jsp:include unconditionally. The included page needs to have control over this. Maybe what we really need is a way for the included page to tell its own Struts tags whether or not to be XHTML formatted or not. Perhaps a specialized version of html:html xhtml=... that was searched for the same way that the standard version is, but does *not* actually emit an html element? I don't think it would be a variation of the html:html element, it would have to be a separate tag, whose only purpose (AFAICS) is to set this flag. Would anyone have a reason to specify that the page should NOT use xhtml? I could envision a html:useXhtml tag (bleah), but should it have an attribute that specifies a true or false value, or can it be attribute-less? -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
On Wed, 13 Nov 2002, David Graham wrote: What would html:isXhtml/ do? This would be the way Craig was seeking for an included page to tell its own Struts tags whether to render XHTML or plain HTML. It would set a *page* context attribute, which the subsequent tags on that page would check. As a corollary, the html:html xhtml=true tag should set the key in *page* scope rather than request scope, so that each page has to make its own decision. If we're going to use a tag I think it should be like this: html:xhtml html:form html:text/ /html:form /html:xhtml Do you mean a separate tag from the html:html tag, instead of using html:html xhtml=true, or are you referring to another tag for the XHTML-ness ;-) of the content? If the former, I'm not sure why we would want that. If the latter, I disagree that it should be a body tag, since it needs to be an all-or-nothing tag, not one that applies only to its body. Any tag inside html:xhtml would be rendered as xhtml. This tag would only be useful for jsp included files. Another question: what if html:xhtml is nested inside html:html xhtml=false? I think we should probably log a warning. In many cases, the resulting output will work, but we need to flag that there's a potential problem. -- Martin Cooper David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST) On Wed, 13 Nov 2002, David Graham wrote: What if we just forgot about the html:xhtml tag altogether? If an included jsp wants to use xhtml they can set the Globals.XHTML_KEY request parameter to true. How would you propose to do that without using scriptlets, and without knowing the value of the key? I think perhaps a html:isXhtml/ tag is the most straightforward solution. -- Martin Cooper Keep in mind that the currently implemented solution works for people using html:html in a jsp and for people using tiles where they can have a layout.jsp like this: html:html xhtml=true tiles:insert attribute=body/ /html:html What's left is how to accomodate people using jsp includes. What do you think? David From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:06:56 -0800 -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] What if we did this: 1. Store a boolean in the request under Globals.XHTML_KEY 2. html:html xhtml=true would set the boolean to true 3. html:xhtml (new tag) would set the boolean to true 4. People could manually set the request attribute if they choose and realize potential problems. This frees you from using html:html, and allows included jsps to set their xhtml status independently of the outer page. Does this accomodate everyone's needs? Well, I have no needs for this, just opinions :) . Despite the simplicity of html:xhtml, I think the name should be a little more different from html:html. I used the example of html:useXhtml to try to make it clearer that the tag isn't generating a HTML tag, and is pretty different from html:html. Also (from your other note), if any tags nested (even through jsp:include) in html:html xhtml=false will NOT use xhtml, then that implies that the other tag also needs a true/false attribute, as opposed to having no attributes (which would imply the tag's presence implies true). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help
Re: [VOTE] How to implement XHMTL support
Martin Cooper wrote: On Wed, 13 Nov 2002, David Graham wrote: What would html:isXhtml/ do? This would be the way Craig was seeking for an included page to tell its own Struts tags whether to render XHTML or plain HTML. It would set a *page* context attribute, which the subsequent tags on that page would check. As a corollary, the html:html xhtml=true tag should set the key in *page* scope rather than request scope, so that each page has to make its own decision. If we're going to use a tag I think it should be like this: html:xhtml html:form html:text/ /html:form /html:xhtml Do you mean a separate tag from the html:html tag, instead of using html:html xhtml=true, or are you referring to another tag for the XHTML-ness ;-) of the content? If the former, I'm not sure why we would want that. If the latter, I disagree that it should be a body tag, since it needs to be an all-or-nothing tag, not one that applies only to its body. I too am confused as to why we would need an additional tag. Any tag inside html:xhtml would be rendered as xhtml. This tag would only be useful for jsp included files. Another question: what if html:xhtml is nested inside html:html xhtml=false? I think we should probably log a warning. In many cases, the resulting output will work, but we need to flag that there's a potential problem. -- Martin Cooper David If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
Ok, I think I agree with the non-body tag setting a page scoped attribute. I really like the style of html:xhtml/ over html:isXhtml/. The is part indicates that it's a question rather than stating that we're using xhtml. Regardless, I'll get the changes in soon so people can start playing with it. David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 11:10:29 -0800 (PST) On Wed, 13 Nov 2002, David Graham wrote: What would html:isXhtml/ do? This would be the way Craig was seeking for an included page to tell its own Struts tags whether to render XHTML or plain HTML. It would set a *page* context attribute, which the subsequent tags on that page would check. As a corollary, the html:html xhtml=true tag should set the key in *page* scope rather than request scope, so that each page has to make its own decision. If we're going to use a tag I think it should be like this: html:xhtml html:form html:text/ /html:form /html:xhtml Do you mean a separate tag from the html:html tag, instead of using html:html xhtml=true, or are you referring to another tag for the XHTML-ness ;-) of the content? If the former, I'm not sure why we would want that. If the latter, I disagree that it should be a body tag, since it needs to be an all-or-nothing tag, not one that applies only to its body. Any tag inside html:xhtml would be rendered as xhtml. This tag would only be useful for jsp included files. Another question: what if html:xhtml is nested inside html:html xhtml=false? I think we should probably log a warning. In many cases, the resulting output will work, but we need to flag that there's a potential problem. -- Martin Cooper David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST) On Wed, 13 Nov 2002, David Graham wrote: What if we just forgot about the html:xhtml tag altogether? If an included jsp wants to use xhtml they can set the Globals.XHTML_KEY request parameter to true. How would you propose to do that without using scriptlets, and without knowing the value of the key? I think perhaps a html:isXhtml/ tag is the most straightforward solution. -- Martin Cooper Keep in mind that the currently implemented solution works for people using html:html in a jsp and for people using tiles where they can have a layout.jsp like this: html:html xhtml=true tiles:insert attribute=body/ /html:html What's left is how to accomodate people using jsp includes. What do you think? David From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:06:56 -0800 -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] What if we did this: 1. Store a boolean in the request under Globals.XHTML_KEY 2. html:html xhtml=true would set the boolean to true 3. html:xhtml (new tag) would set the boolean to true 4. People could manually set the request attribute if they choose and realize potential problems. This frees you from using html:html, and allows included jsps to set their xhtml status independently of the outer page. Does this accomodate everyone's needs? Well, I have no needs for this, just opinions :) . Despite the simplicity of html:xhtml, I think the name should be a little more different from html:html. I used the example of html:useXhtml to try to make it clearer that the tag isn't generating a HTML tag, and is pretty different from html:html. Also (from your other note), if any tags nested (even through jsp:include) in html:html xhtml=false will NOT use xhtml, then that implies that the other tag also needs a true/false attribute, as opposed to having no attributes (which would imply the tag's presence implies true). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
Re: [VOTE] How to implement XHMTL support
On Wed, 13 Nov 2002, Eddie Bush wrote: big-snip/ If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). It can't, and that's in part what Craig pointed out. Since each included page must also be XHTML, each of those pages should state explicitly that it is XHTML, instead of having the decision about whether or not to generate XHTML be made externally (i.e. on the topmost page). Given that the non-Struts tags on the page must also be explicitly XHTML, that makes sense. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
On Wed, 13 Nov 2002, David Graham wrote: Ok, I think I agree with the non-body tag setting a page scoped attribute. I really like the style of html:xhtml/ over html:isXhtml/. The is part indicates that it's a question rather than stating that we're using xhtml. I'm not that fussed about the name - isXhtml, useXhtml, or just xhtml. I do agree with David Karr that just xhtml is rather subtle, but I'm not going to veto it. ;-) -- Martin Cooper Regardless, I'll get the changes in soon so people can start playing with it. David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 11:10:29 -0800 (PST) On Wed, 13 Nov 2002, David Graham wrote: What would html:isXhtml/ do? This would be the way Craig was seeking for an included page to tell its own Struts tags whether to render XHTML or plain HTML. It would set a *page* context attribute, which the subsequent tags on that page would check. As a corollary, the html:html xhtml=true tag should set the key in *page* scope rather than request scope, so that each page has to make its own decision. If we're going to use a tag I think it should be like this: html:xhtml html:form html:text/ /html:form /html:xhtml Do you mean a separate tag from the html:html tag, instead of using html:html xhtml=true, or are you referring to another tag for the XHTML-ness ;-) of the content? If the former, I'm not sure why we would want that. If the latter, I disagree that it should be a body tag, since it needs to be an all-or-nothing tag, not one that applies only to its body. Any tag inside html:xhtml would be rendered as xhtml. This tag would only be useful for jsp included files. Another question: what if html:xhtml is nested inside html:html xhtml=false? I think we should probably log a warning. In many cases, the resulting output will work, but we need to flag that there's a potential problem. -- Martin Cooper David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST) On Wed, 13 Nov 2002, David Graham wrote: What if we just forgot about the html:xhtml tag altogether? If an included jsp wants to use xhtml they can set the Globals.XHTML_KEY request parameter to true. How would you propose to do that without using scriptlets, and without knowing the value of the key? I think perhaps a html:isXhtml/ tag is the most straightforward solution. -- Martin Cooper Keep in mind that the currently implemented solution works for people using html:html in a jsp and for people using tiles where they can have a layout.jsp like this: html:html xhtml=true tiles:insert attribute=body/ /html:html What's left is how to accomodate people using jsp includes. What do you think? David From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:06:56 -0800 -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] What if we did this: 1. Store a boolean in the request under Globals.XHTML_KEY 2. html:html xhtml=true would set the boolean to true 3. html:xhtml (new tag) would set the boolean to true 4. People could manually set the request attribute if they choose and realize potential problems. This frees you from using html:html, and allows included jsps to set their xhtml status independently of the outer page. Does this accomodate everyone's needs? Well, I have no needs for this, just opinions :) . Despite the simplicity of html:xhtml, I think the name should be a little more different from html:html. I used the example of html:useXhtml to try to make it clearer that the tag isn't generating a HTML tag, and is pretty different from html:html. Also (from your other note), if any tags nested (even through jsp:include) in html:html xhtml=false will NOT use xhtml, then that implies that the other tag also needs a true/false attribute, as opposed to having no attributes (which would imply the tag's presence implies true). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail
Re: [VOTE] How to implement XHMTL support
Martin Cooper wrote: On Wed, 13 Nov 2002, Eddie Bush wrote: big-snip/ If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). It can't, and that's in part what Craig pointed out. Since each included page must also be XHTML, each of those pages should state explicitly that it is XHTML, instead of having the decision about whether or not to generate XHTML be made externally (i.e. on the topmost page). Given that the non-Struts tags on the page must also be explicitly XHTML, that makes sense. Ah - so the tag would serve to say This is XHTML-compliant so that you could then say Wait a sec - you asked for an XHTML document - but you included this and it's not XHTML. I think I understand the reasoning better now. Sorry about being so thick-headed. I figured I was confuzzled, but I wanted to be clear. Thanks Martin ;-) -- Martin Cooper -- Eddie Bush -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
Neither am I. Absolutely correct naming is almost impossible, it's just a good goal. If you can't make it perfect, the documentation should take you the rest of the way. Make sure that the documentation for the html and xhtml tags refer to each other. A boilerplate comment about this in each HTML tag might be useful also. -Original Message- From: Martin Cooper [mailto:martinc;apache.org] On Wed, 13 Nov 2002, David Graham wrote: Ok, I think I agree with the non-body tag setting a page scoped attribute. I really like the style of html:xhtml/ over html:isXhtml/. The is part indicates that it's a question rather than stating that we're using xhtml. I'm not that fussed about the name - isXhtml, useXhtml, or just xhtml. I do agree with David Karr that just xhtml is rather subtle, but I'm not going to veto it. ;-) -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
The future of the struts html tags is unclear. JavaServer Faces will largely replace their functionality. I just wanted to get simple xhtml support into Struts now because it's a requirement on some projects. It's easy enough to setup xhtml with the current nightly builds and enhancements I'll be making over the next few days. David From: Hajratwala, Nayan (N.) [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 15:18:57 -0500 I think it would be worth investigating whether or not XHTML is fully backward compatible with HTML 4.01 (which i think it is), and then ONLY rendering XHTML, and forgetting about HTML altogether. Of course, this would have the be a version 2.0 enhancement because it would likely break some people's pages. Anyone agree? --- - Nayan Hajratwala - Chikli Consulting LLC - http://www.chikli.com -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Wednesday, November 13, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Ok, I think I agree with the non-body tag setting a page scoped attribute. I really like the style of html:xhtml/ over html:isXhtml/. The is part indicates that it's a question rather than stating that we're using xhtml. Regardless, I'll get the changes in soon so people can start playing with it. David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 11:10:29 -0800 (PST) On Wed, 13 Nov 2002, David Graham wrote: What would html:isXhtml/ do? This would be the way Craig was seeking for an included page to tell its own Struts tags whether to render XHTML or plain HTML. It would set a *page* context attribute, which the subsequent tags on that page would check. As a corollary, the html:html xhtml=true tag should set the key in *page* scope rather than request scope, so that each page has to make its own decision. If we're going to use a tag I think it should be like this: html:xhtml html:form html:text/ /html:form /html:xhtml Do you mean a separate tag from the html:html tag, instead of using html:html xhtml=true, or are you referring to another tag for the XHTML-ness ;-) of the content? If the former, I'm not sure why we would want that. If the latter, I disagree that it should be a body tag, since it needs to be an all-or-nothing tag, not one that applies only to its body. Any tag inside html:xhtml would be rendered as xhtml. This tag would only be useful for jsp included files. Another question: what if html:xhtml is nested inside html:html xhtml=false? I think we should probably log a warning. In many cases, the resulting output will work, but we need to flag that there's a potential problem. -- Martin Cooper David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST) On Wed, 13 Nov 2002, David Graham wrote: What if we just forgot about the html:xhtml tag altogether? If an included jsp wants to use xhtml they can set the Globals.XHTML_KEY request parameter to true. How would you propose to do that without using scriptlets, and without knowing the value of the key? I think perhaps a html:isXhtml/ tag is the most straightforward solution. -- Martin Cooper Keep in mind that the currently implemented solution works for people using html:html in a jsp and for people using tiles where they can have a layout.jsp like this: html:html xhtml=true tiles:insert attribute=body/ /html:html What's left is how to accomodate people using jsp includes. What do you think? David From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 10:06:56 -0800 -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] What if we did this: 1. Store a boolean in the request under Globals.XHTML_KEY 2. html:html xhtml=true would set the boolean to true 3. html:xhtml (new tag) would set the boolean to true 4. People could manually set the request attribute if they choose and realize potential problems. This frees you from using html:html, and allows included jsps to set their xhtml status independently of the outer page. Does
Re: [VOTE] How to implement XHMTL support
Hi, A Dimecres 13 Novembre 2002 20:45, Martin Cooper va escriure: On Wed, 13 Nov 2002, Eddie Bush wrote: big-snip/ If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). It can't, and that's in part what Craig pointed out. Since each included page must also be XHTML, each of those pages should state explicitly that it is XHTML, instead of having the decision about whether or not to generate XHTML be made externally (i.e. on the topmost page). Given that the non-Struts tags on the page must also be explicitly XHTML, that makes sense. The document doctype (xhtml1, html401) is global, like the character encoding or some response headers. There is no sense in changing the doctype flag in included pages. If you develop a page to be included and you use tags other than struts-html, like br or br / there is no way to reuse this page in both xhtml and html, with or without html:isXhtml/, html:html xhtml=true, etc but if a developer is able to create a page to be included that only uses struts-html and/or other custom tags, with the html:isXhtml/ aproach she will not be able to reuse its page to generate xhtml or html Salut! -- Antoni Reus -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How to implement XHMTL support
The developer must make a choice between html and xhtml. This choice is minor as xhtml is compatible with current browsers. Included jsps should not be influenced by the includer file; they must decide if they're xhtml or html. That's the point behind the html:xhtml tag, to tell struts html library tags to render in xhtml. If you want to reuse a jsp in an html project then don't code it with xhtml tags. David From: Antoni Reus [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 22:53:36 +0100 Hi, A Dimecres 13 Novembre 2002 20:45, Martin Cooper va escriure: On Wed, 13 Nov 2002, Eddie Bush wrote: big-snip/ If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). It can't, and that's in part what Craig pointed out. Since each included page must also be XHTML, each of those pages should state explicitly that it is XHTML, instead of having the decision about whether or not to generate XHTML be made externally (i.e. on the topmost page). Given that the non-Struts tags on the page must also be explicitly XHTML, that makes sense. The document doctype (xhtml1, html401) is global, like the character encoding or some response headers. There is no sense in changing the doctype flag in included pages. If you develop a page to be included and you use tags other than struts-html, like br or br / there is no way to reuse this page in both xhtml and html, with or without html:isXhtml/, html:html xhtml=true, etc but if a developer is able to create a page to be included that only uses struts-html and/or other custom tags, with the html:isXhtml/ aproach she will not be able to reuse its page to generate xhtml or html Salut! -- Antoni Reus -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How to implement XHMTL support
Hi, A Dimecres 13 Novembre 2002 23:06, David Graham va escriure: The developer must make a choice between html and xhtml. This choice is minor as xhtml is compatible with current browsers. Included jsps should not be influenced by the includer file; they must decide if they're xhtml or html. That's the point behind the html:xhtml tag, to tell struts html library tags to render in xhtml. If you want to reuse a jsp in an html project then don't code it with xhtml tags. David I don't completely agree with this: Included jsps should not be influenced by the includer file; they must decide if they're xhtml or html. I think included jsps must not decide a thing that involves the whole request! Anyway I think I can see your point, included jsps should always output the same, xhtml or html, so you can rely on the output of the jsp, even if you are including it from a non-struts jsp page,.. oh well, I think now I completely agree with the above :-) Salut! -- Antoni Reus From: Antoni Reus [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] How to implement XHMTL support Date: Wed, 13 Nov 2002 22:53:36 +0100 Hi, A Dimecres 13 Novembre 2002 20:45, Martin Cooper va escriure: On Wed, 13 Nov 2002, Eddie Bush wrote: big-snip/ If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). It can't, and that's in part what Craig pointed out. Since each included page must also be XHTML, each of those pages should state explicitly that it is XHTML, instead of having the decision about whether or not to generate XHTML be made externally (i.e. on the topmost page). Given that the non-Struts tags on the page must also be explicitly XHTML, that makes sense. The document doctype (xhtml1, html401) is global, like the character encoding or some response headers. There is no sense in changing the doctype flag in included pages. If you develop a page to be included and you use tags other than struts-html, like br or br / there is no way to reuse this page in both xhtml and html, with or without html:isXhtml/, html:html xhtml=true, etc but if a developer is able to create a page to be included that only uses struts-html and/or other custom tags, with the html:isXhtml/ aproach she will not be able to reuse its page to generate xhtml or html Salut! -- Antoni Reus -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
Just so I understand, you're experimenting with making tags generated from a jsp:include be xhtml-compliant even if the original page wasn't specified as being xhtml-compliant? It seems to me that XHTML compliance is an attribute of an html element and its nested elements (including the associated DOCTYPE), and not an attribute of an HTTP request. This would mean that a page that was jsp:included would generate different output depending on what page included it. I'd say that choice 1 (only affecting the elements nested in the html element), which I assume is what you've already done, is preferable to choice 2 (runtime determination). -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] I've updated that html taglib tags to output xhtml when they are nested in a html:html xhtml=true tag. This was very simple to do and resulted in minor code changes. Users have suggested this approach: 1. Add Globals.XHTML_KEY which is a boolean request scoped attribute 2. html tags check for that request attribute being true and output accordingly. 3. The html:html tag sets this request attribute when it's xhtml attribute is true. The second approach allows the tags to output xhtml without relying on the html:html tag. This allows people to construct pages with jsp includes. The first approach is logically clearer (to me) and you can use tiles to modularly construct the pages like includes. Approach 2 may be confusing because you would have to remember all the places you may have set that request attribute. So, do we go with 1, 2 or both? -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
Yes, I have already implemented choice 1. Good points David. Dave From: Karr, David [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: [VOTE] How to implement XHMTL support Date: Tue, 12 Nov 2002 16:14:10 -0800 Just so I understand, you're experimenting with making tags generated from a jsp:include be xhtml-compliant even if the original page wasn't specified as being xhtml-compliant? It seems to me that XHTML compliance is an attribute of an html element and its nested elements (including the associated DOCTYPE), and not an attribute of an HTTP request. This would mean that a page that was jsp:included would generate different output depending on what page included it. I'd say that choice 1 (only affecting the elements nested in the html element), which I assume is what you've already done, is preferable to choice 2 (runtime determination). -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] I've updated that html taglib tags to output xhtml when they are nested in a html:html xhtml=true tag. This was very simple to do and resulted in minor code changes. Users have suggested this approach: 1. Add Globals.XHTML_KEY which is a boolean request scoped attribute 2. html tags check for that request attribute being true and output accordingly. 3. The html:html tag sets this request attribute when it's xhtml attribute is true. The second approach allows the tags to output xhtml without relying on the html:html tag. This allows people to construct pages with jsp includes. The first approach is logically clearer (to me) and you can use tiles to modularly construct the pages like includes. Approach 2 may be confusing because you would have to remember all the places you may have set that request attribute. So, do we go with 1, 2 or both? -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How to implement XHMTL support
We need to ensure that HTML taglib tags in included JSP pages also heed the xhtml attribute. That isn't the case with what's there now, because findAncestorWithClass() will fail for the tags in the included pages. Note that this is why the form tag stores itself in a request attribute. Originally, it also used findAncestorWithClass(), but it was changed to allow forms to span pages. So I see two ways of handling this: A) Have the html:html tag store itself in a request attribute, and change BaseHandlerTag.isXhtml() to grab the tag from there before calling getXhtml(). B) Have the html:html tag store the value of its 'xhtml' attribute as a request attribute, and use that in BaseHandlerTag.isXhtml(). Of these, I prefer the first approach because it makes it harder for people to futz (technical term :) with the value in their pages. -- Martin Cooper On Tue, 12 Nov 2002, David Graham wrote: I've updated that html taglib tags to output xhtml when they are nested in a html:html xhtml=true tag. This was very simple to do and resulted in minor code changes. Users have suggested this approach: 1. Add Globals.XHTML_KEY which is a boolean request scoped attribute 2. html tags check for that request attribute being true and output accordingly. 3. The html:html tag sets this request attribute when it's xhtml attribute is true. The second approach allows the tags to output xhtml without relying on the html:html tag. This allows people to construct pages with jsp includes. The first approach is logically clearer (to me) and you can use tiles to modularly construct the pages like includes. Approach 2 may be confusing because you would have to remember all the places you may have set that request attribute. So, do we go with 1, 2 or both? David _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
