> 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...
Stripes Tags produces code that is XHTML compliant
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.