[
http://www.stripesframework.org/jira/browse/STS-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11950#action_11950
]
Nikolaos commented on STS-751:
------------------------------
Iwao,
> You would have seen many things (html dialects, doc types, css hacks, etc.)
> come and go if you're working long enough as a web developer.
Ummm... sure... technology is "always" evolving... and that is why software is
continuously upgraded... NO? Or should Stripes have say never leveraged Java
annotations for example because... you know... one day they will be superseded
by something else. Your really missing the point... I suggest understanding
what is being proposed by EXAMINING the proposed code VS. arguing in general
terms might be worth your time...
> That's why I feel uneasy when a patch trying to absorb specific html dialect
> or browsers' misbehavior is proposed against the framework core.
What browser misbehaviour? Come on let's not start adding FUD to get our point
across. As for the other half of your point:
HTML 4.01 and XHTML 1.0/1.1 are current technologies. HTML 5 is an emerging
new standard. You either develop HTML web pages OR you develop XHTML web
pages... unless there is some other secret sauce I don't understand... and you
have been around long enough and you develop web pages in some other technology.
Moreover, this may be a SHOCKER to you but Stripes Tags PRODUCE XHTML code...
yes INDEED a Tag library by its very nature will produce an element that guess
what... is XHTML or HTML compliant code.
Furthermore, Stripes today assumes that EVERYONE is developing XHTML compliant
code which is INCORRECT. I develop HTML 4.01 web pages today and will most
likely develop HTML 5.0 a year from now both of which WHEN validated NOT by the
web browser but by a w3c validator - AND if you have been in the game as long
as you say you have then I assume you do indeed VALIDATE your code (Right?) -
will result in validation warnings TODAY and TOMORROW.
Of course one can ignore validation warnings so in your opinion Stripes Tags
should NOT produce CORRECT code 100% of the time. Interesting logic and
interesting point indeed. Why bother... right... its going to change 3 years
from now... .
> It is relatively easy to add a new option, but it's difficult (if possible)
> to remove it afterwards, you know.
WHY in the world would you want to remove it?????? Unless you envision a world
were in HTML 5 will not get released and HTML 4.01 doesn't exist and 100% of
all web pages produced from today onward will be XHTML compliant WHY IN THE
WORLD would you want to remove this improvement. It's an improvement for a
reason... .
ALSO guess what... developers do ZERO once the improvement is in place and
Stripes Tags will continue to assume XHTML compliant code. Since you haven't
read the code and I doubt you ever will but will argue regardless here is the
nutshell...
TODAY:
Stripes Tags produces code that is XHTML compliant
After improvement:
a) xhtml=true OR no explicit declaration and Stripes Tags has an extra if
condition that produces XHTML compliant code
a) xhtml=false and Stripes Tags has an extra if condition that produces HTML
compliant code
How is that a bad thing?????
> What if we have a way to override the behavior of original stripes tags by a
> extension mechanism like the one Stripes already uses for other components.
> This, of course, must be a bigger change than the one you are working on, but
> would be a better/cleaner solution in a long run. How do you think?
Seriously... how would that EVEN work? Here you argue against a simple
variable and if condition in a Tag library and suggest baking an extension that
would somehow hook into the framework that the Stripes Tag libraries would have
to look for and somehow leverage. Wow... . So what do I think... an awful
idea... that many would be very much against.
The improvement relates to Stripes Tags NOT the Stripes framework code. If you
understood that separation and where the change is proposed I imagine you
wouldn't be making this suggestion.
I think you need to take 5 minutes to look at the proposed code.
> Lastly, let me interpret my comment about Struts...Based on the KISS
> principle, what I was trying to say is: 'any sensible developers would choose
> Stripes for its simplicity (like we did)'. I thought it was obvious enough,
> sorry.
Yes and any sensible developer that chooses a framework simple or not would
like to see it evolve and improve. If you believe that Stripes should be
baselined today and anyone who wants to improve it should look at Struts even
if they suggest adding a warranted improvement with ZERO additional
configuration for the developer then I would say I understand your argument :-)
Here's some irony... this improvement uses the KISS principle... backwards
compatible... ZERO additional configuration... encapsulated smarter Tag
libraries... yet you argue against it... . I'm at a loss... and am done.
> 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-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
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
