JSP and HTML/JavaScript do not play together

Again... I think IDEA is headed on the wrong direction, trying to validate the resulting HTML. Really guys, dynamic web pages are way too complex to be validated -- give us color highlighting and tag name completion, and we'll be happy everafter.

Hi,

There will be no check for script generated attributes/values/etc.

lllopo wrote:

The following causes a "duplicate attribute OnClick" :

<tr
<% if(...)
{%>onClick="..."<%}
else
{%>onClick="..."<%}
%>


This means that IDEA do not take in consideration the JSP statements, while parsing HTML and JavaScript. Is this a bug or there's no way to implement it the right way ?

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Even on static HTML+javascript any validity check is still too much. For example, here's a construct I use a lot:

... Edit Remove]]>

...

function submitFormEdit() {
document.getElementById('theFormId').action = '/path/edit';
document.getElementById('theFormId').submit();
}

IDEA will complain that the form is missing the required attribute 'action', but as you can see, the form will have it's action set at runtime. And this is just a static web page! If browsers won't check my web page for validity so hard, why should IDEA?

Well, this error will be a warning.

Marcus Brito wrote:

Even on static HTML+javascript any validity check is still too much. For example, here's a construct I use a lot:

<form id="theFormId" style=>
<input type="hidden" name="fieldOne" value="xxx"/>
<input type="hidden" name="fieldTwo" value="xxx"/>
</form>

..

<a href="#" onclick="submitFormEdit()">Edit</a>
<a href="#" onclick="submitFormRemove()">Remove</a>

..

function submitFormEdit() {
document.getElementById('theFormId').action = '/path/edit';
document.getElementById('theFormId').submit();
}

IDEA will complain that the form is missing the required attribute 'action', but as you can see, the form will have it's action set at runtime. And this is just a static web page! If browsers won't check my web page for validity so hard, why should IDEA?

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Well, don't forget the "missing attribute 'type'" for the "script" tag then :-). 99% of the programmers do not define type anyway, so it should be warning too.

+1

"lllopo" <no_mail@jetbrains.com> wrote in message
news:18539944.1118840818470.JavaMail.itn@is.intellij.net...

Well, don't forget the "missing attribute 'type'" for the "script" tag
then :-). 99% of the programmers do not define type anyway, so it should
be warning too.

Maxim,
I think the current state is the worse of all options U have. Better :
1. Make this thing fully working. Well, if it's not possible or to expensive (slow, I mean) - ok, then this is not an option.
2. Remove it (no checking) - better then a page full of red warnings.
3. Add the very nice Word spell checker option "Ignore this error" ... or (sorry if this is present and I can't find it) just add per file turn on/off validation (of course per type too. I mean separtely turn on/off the JSP, HTML and JavaScript validation).

What do U think ?

3371

Brad wrote:

+1

"lllopo" <no_mail@jetbrains.com> wrote in message
news:18539944.1118840818470.JavaMail.itn@is.intellij.net...

>>Well, don't forget the "missing attribute 'type'" for the "script" tag
>>then :-). 99% of the programmers do not define type anyway, so it should
>>be warning too.

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

ok, 10x. Obviously we understand each other with one word :)))).

lllopo wrote:

Well, don't forget the "missing attribute 'type'" for the "script" tag then :-). 99% of the programmers do not define type anyway, so it should be warning too.

Really, this should only be a warning if you use this:
]]>

as specified in the HTML 4.0 spec:


"As HTML does not rely on a specific scripting language, document authors must explicitly
tell user agents the language of each script. This may be done either through a default
declaration or a local declaration
...
Documents that do not specify default scripting language information and that contain
elements that specify an intrinsic event script are incorrect. "

>add per file turn on/off validation (of course per type >too. I mean separtely turn on/off the JSP, HTML and >JavaScript validation).

I vote against the idea of making us fiddle with several options, or worse setting ignore this but not that, while working. The interaction as it was before the validation era, i.e. simple autocomplete was well designed. If this must be empowered, it should be in a way that doesn't bother the developer, by for example using different colors for different validations, or any visual idea that makes things clear and does not obscure the main point, i.e. the jsp validity, for which html or js validity (which in all cases can only be approximately defined) is secondary.

Marcus Brito wrote:

Again... I think IDEA is headed on the wrong direction, trying to
validate the resulting HTML. Really guys, dynamic web pages are way

I actually think this whole JSP thing has been, well, aside from looking
bad to us EAPers, an interesting experiment.

JetBrains had a hefty high goal, and they've aimed for it, if they could
pull it off we'd all be in love and giving them boxes of donuts daily.
But as we're finding out, its alot harder to do in practise ( at least,
to the level and direction of the current DEVELOPMENT STREAM ( we seem
to forget that part sometimes I think ).

I'm sure things will come out kick arse and shiny on the other end come
release...

I agree with you.

Please see the attached file.

1. Would you share with us, please, how do you define which validity is more important ?!?!?!? For me - the hardest thing to debug is the most important to validate. The HTML has never been easy to read, e.g. to find errors. Besides how do U define the HTML as secondary in a file which is 2-3% JSP tags and the rest 97% is HTML ?!?!?!?

2. If a JSP with 60-70 validation errors doesn't bothers U, then U must be with steel nerves ... or comlpetely blind. But in many cases the JSP structure allows good HTML validation (especially when using only JSP tags), which is useful, so ... tell me, which is the most obvious solution that allows the validation to be present for some JSPs , but not present for the others that do not allow to do it right ?

3. Would U also define "bother" ? For me, 2 millions colors in the source text are not bothering - they drive me crazy. So ... I will gladly bother myself to turn them off. "Fiddle" means that U will be forced to do something, which is not the case - if someone (like U do) don't want to use this option - feel free not to use it :-).

4. Why do U think that more colors means more clear ?!?!?

Nick: thank you for the examples, they make the point clearer.

Dear Mr. Illopo, by the number of !? of your post, you seem personally irritated by my objections, I surely didn't mean to offend anyone, but just to make my point.

I believe that compiler - validity is different and in all cases more important then html validity for a jsp page. I didn't say adding a million colors, but finding an ergonomic solution to get the best of all validations all the time; one way would be to add 1 color for signalling html invalidity. Adding options instead is often a sign of bad interface design.

The "?!?!" are in response of "fiddle" and "bother". It seemed like U are wondering "How someone even can think about it ?" , while I still find the idea not bad. Sorry, if my tone was sharper than needed.

Sure, I would even agree with your point, if there were some constructive arguments. "This would bother someone" means nothing. "Old fashioned" ? Why not if it's handy and does the trick ?
Besides this just one of variants. Do not vote "against" something when it's not alone. Vote "for" something or propose something new - I'm far from the idea that these are the best and only solutions. Just use better arguments. For example I still can't see a single example why the java validation is more important then the HTML validation in a JSP (100% equvalent for me though). And once again about the colors - does the color matters when the validation is wrong ?

Once again, sorry if I was too offensive, just try to post ideas + solid arguments and less personal preferences.

lllopo wrote:

The "?!?!" are in response of "fiddle" and "bother". It seemed like U are wondering "How someone even can think about it ?" , while I still find the idea not bad. Sorry, if my tone was sharper than needed.

Sure, I would even agree with your point, if there were some constructive arguments. "This would bother someone" means nothing. "Old fashioned" ? Why not if it's handy and does the trick ?
Besides this just one of variants. Do not vote "against" something when it's not alone. Vote "for" something or propose something new - I'm far from the idea that these are the best and only solutions. Just use better arguments. For example I still can't see a single example why the java validation is more important then the HTML validation in a JSP (100% equvalent for me though). And once again about the colors - does the color matters when the validation is wrong ?

Once again, sorry if I was too offensive, just try to post ideas + solid arguments and less personal preferences.

"Ooh, I can't keep it in... I can't keep it in... i gotta let it out..."

I'm sorry. I know people will hate me for whining about this, but it's
driving me crazy.

Please, the word "you" is spelled "Y-O-U", not "U". It's just two measly
letters more, and will make you sound a lot more educated.

Again, sorry for whining.

/Kreiger

It's true that it's hard to debug JSP files. Most of the times, simple HTML tags that do not have a closing tag or an overlapping tag messes up the compilation of JSP file to Servlet. Worst is, sometimes there is no compilation error but errors occured during runtime. I think JSP/HTML/Struts were the most important to validate. Javascript, is just secondary, since the browser will do the job.

Quite right.

Whatever.
It's just two measly letters less, and will make you write a lot more faster. :))))))

lllopo wrote:

Whatever.
It's just two measly letters less, and will make you write a lot more faster. :))))))

a lot more worser 2

whileyouareatitleaveoutthespacescapitolizationandpunctuation2muchquicker ;))))))

nick wrote:

It's true that it's hard to debug JSP files. Most of the times, simple HTML tags that do not have a closing tag or an overlapping tag messes up the compilation of JSP file to Servlet. Worst is, sometimes there is no compilation error but errors occured during runtime. I think JSP/HTML/Struts were the most important to validate. Javascript, is just secondary, since the browser will do the job.

Your priorities may be ok, but the one that is the easiest to validate is the javascript.
The JSP/HTML/Struts/TaglibOfTheMonth/... is the difficult combination.

I have a feeling that the only way that they will have successful validation of JSP files is
if they precompile the jsp into java and validate the java. I don't think that it's even
possible to validate the HTML since it can vary based on data only available at runtime.
IDEA has no way of knowing what HTML or partial HTML is being produced by the custom tag
libraries.

Of course, this does not apply to jspx since it must be valid xml. You may still produce
invalid HTML from a badly written custom tag, but there is no way for IDEA to determine that.

:))))

The case you describe is really complicated and really impossible to predict, e.g. validate. Another case impossible to predict are the fractionnal JSP's for example. The question is about the possibility (or impossibility) to validate the "visible" code (see the simple example in the first post).

To be honest, I expected to hear the IDEA team comments about the problem and about the possible solutions we're discussing here, but ... :)

We were listening and thinking :). From my point of view there are
different coding styles for JSP which produce different amount of
failures in our analysis. There are no ideal solution in this situation
but the most acceptable one is to allow to customize which errors to
show. There is the only question --- default settings. What do you think
on them?

IK

In article <d8v0bb$pgm$1@is.intellij.net>,
"Igor Kuralenok (JetBrains)" <ik@intellij.com> wrote:

We were listening and thinking :). From my point of view there are
different coding styles for JSP which produce different amount of
failures in our analysis. There are no ideal solution in this situation
but the most acceptable one is to allow to customize which errors to
show. There is the only question --- default settings. What do you think
on them?

What ever you have right now seems to work fine on my end, I guess my
coding style is standard with your current settings.

R

I think the defaults should keep the current state , so there will be no change for the developpers that do not like the feature and also do not like to deal with many settings. But more important is to make the customization option easy to access and change, 'cause it will vary from file to file and from file version to file version.