[
http://www.stripesframework.org/jira/browse/STS-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11990#action_11990
]
Nikolaos commented on STS-751:
------------------------------
Okay Iwao. Thanks for the feedback.
So here are the options *thus far* on the table:
1) Timothy's suggestion: Adding an additional optional argument to
LayoutDefinition ala Struts that defaults to xhtml=true for backwards
compatability.
Cons: Not all output is HTML fragments and not all output occurs within a
LayoutDefinition tag (e.g. someone may be using Tiles or SiteMesh); this is
besides the issues of getting this work with nested Layouts (which are
problematic in 1.5.4 Snapshot).
2) Iwao's suggestion: Pretty simple... swap out the implemented Stripes jar
with one that hard codes for HTML vs XHTML
Cons: Too rigid in that in order to produce the *correct* HTML / XHTML markup
I need to swap out my version of Stripes. Also how is this maintained down the
road? What happens with version 1.5.4 or 1.6.0... will we always maintain 2
versions of the libraries. I know you were simply offering a solution which is
great but I don't think any one developer exclusively works with HTML or XHTML
documents and even if they did the maintenance and management of this would be
too arduous. A solution definitely. But I would be apt to tolerate the
current validation warnings than go down this avenue.
3) Timothy's 2nd suggestion: Add the optional argument to a <form> tag.
Cons: It appears that as LayoutDefinition didn't seem appropriate as per Con
in 1) above and that this alternative suggestion was to be very specific and
put it on the <form> tag but that doesn't work for other reasons. Primarily
what if I have output that does not include a form tag... e.g. what if I just
have Ajax output or some other fragment. We need a more flexible solution.
4) Ben's suggestion tweak on Timothy's suggestion which I simply renamed as:
<s:doctypeOptions xhtml="false" />
Cons: A new tag needs to be implemented / authored and documented.
In fact, although developers may work with both HTML and XHTML one thing is
certain... for any given web page the document or fragment is either HTML or
XHTML (or of course JS, etc...) but never both HTML and XHTML interspersed.
What that tells me is that the ideal solution should be configurable
dynamically and work equally well on an entire web page or even a fragment and
should be flexible enough to turn on or off for a given page. Solution 4)
provides that IMO.
What do others think? Any other solutions?
--Nikolaos
> Add support ala Struts to generate HTML or XHTML compliant close tags
> ---------------------------------------------------------------------
>
> Key: STS-751
> URL: http://www.stripesframework.org/jira/browse/STS-751
> Project: Stripes
> Issue Type: Improvement
> Components: Tag Library
> Affects Versions: Release 1.5
> Environment: No specific OS required; no specific Java version
> required; etc...
> Reporter: Nikolaos
> Priority: Minor
> Attachments: stripes-html4-input-0.1.jar, stripes-xhtml-patch.tar.gz,
> stripes-xhtml-patches.tar.gz
>
>
> HTML and XHTML documents have some key differences.
> For example - if we consider the <input> tag:
> - In HTML, the <input> tag has no end tag e.g. <input name="website.url"
> type="text" size="30">
> - In XHTML, the <input> tag must be properly closed, like this <input />
> e.g. <input name="website.url" type="text" size="30" />
> Stripes 1.5.x however does not have a mechanism to discern whether or not to
> properly close tags or not and as such takes the safer approach which is to
> explicitly close tags as it results in valid XHTML and is not an error for
> HTML but results in a warning when validating HTML documents. Although the
> latter is not a critical issue it does result in needless or unnecessary
> complaints when validating and as such is an annoyance albeit minor.
> Struts since 1.x has solved this issue quite easily by allowing the inclusion
> of the xhtml="true" attribute to mark that closure is required (false
> indicates no closure). In this manner authors of XHTML and HTML documents
> are equally satisfied in not having any errors or extraneous warnings.
> Timothy Stone had reported this issue and classified it as a bug here:
> http://www.stripesframework.org/jira/browse/STS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11931#action_11931
> The issue was rightly closed as "Not a bug" as most of the discussion was
> based on a non-w3c validator which yielded results that considered the
> validation unsuccessful which is not the case with the w3c validator (not to
> mention that it is irrelevant whether or not XHTML is considered dead or we
> should align to HTML 5 - etc...).
> As such this issue report is a re-statement of the above closed issue
> reported as an improvement and setting the stage for patch to be attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
