Created attachment 130912 [details]
defective xhtml file - was formatted

Created attachment 130913 [details]
non defective xhtml file - formatting becomes defective

this bug is in netbeans 7.3 RC1 and earlier versions.

Do you mean the ones in onmouseover etc.?


 <bookstore:area id="map1" value="#{Book201}"
                                    onmouseover="resources/images/book_201.jpg"
                                    onmouseout="resources/images/book_all.jpg"
                                    targetImage="mapImage"/>


I think this is more likely JavaScript related as it doesn't happen if I place "/" in other attribute that does not expect JS code. Reassigning to JavaScript|Formatting

This seems to be pretty ugly. I think majority of the developers (I would even say all of them) expect onmouseover to be javascript. And we handle it that way so the attribute is formatted by JS formatter. As your onmouseover is semantically different there are only two options in general (as we can't really guess a semantical meaning from the source file):

1) to not to handle it as JS - that would imo cause a major negative feedback reported as P1 blocker
2) to accept it on your side and to not to use different semantic for such widely used attributes

I think option 2) is much better. Are there any other options?

I am still researching where exactly this xhtml example came from - i did not write it.

However it is from some official Sun/Oracle example - either Jersey/Glassfish/JSF2 or some Netbeans Rest example - i will report back when i determine where i obtained this file.

You do not have a solution - this is a REGRESSION -- this has never been a
problem before now, not until additional JavaScript support added to Netbeans.

Perhaps an editor/formatter switch/checkbox could be added somewhere.

It is not acceptable to assume everybody is writing javascript - i dont  - i have been using netbeans since 2005 for java EE and JSF, JAX-RPC, JAX-WS, and JAX-RS.

We need to come up with a solution - especially since the source code that gets broken by formatting is provided by Sun/Oracle/Netbeans.

i see in the comments - i originally indicated the source code is from a java ee 6  tutorial example.

(In reply to comment #6)
> You do not have a solution - this is a REGRESSION -- this has never been a
> problem before now, not until additional JavaScript support added to Netbeans.
Before now there was no JS formatter.

> Perhaps an editor/formatter switch/checkbox could be added somewhere.
What would be the label of the checkbox?

> It is not acceptable to assume everybody is writing javascript - i dont  - i
> have been using netbeans since 2005 for java EE and JSF, JAX-RPC, JAX-WS, and
> JAX-RS.
We don't assume everybody is writing javascript. We just assume onmouseover attribute in xhtml is javascript.

Marku can we do anything about that?

see comment 7 - this xhtml jsf file that won't format is from a java ee 6 tutorial example. - glassfish/jsf example

It wont format - so how should the jsf xhtml have been written so that it would format properly with the JS Formatter ?

if standard jsf xhtml files are to have problems with the JS Formatter then I think this is a big problem.

(In reply to comment #9)
> see comment 7 - this xhtml jsf file that won't format is from a java ee 6
> tutorial example. - glassfish/jsf example
Does it make any difference? Even java ee samples may be wrong/suboptimal.

> 
> It wont format - so how should the jsf xhtml have been written so that it would
> format properly with the JS Formatter ?
Do not use de facto standard html attributes such as onmouseclick, onmouseover etc. with overridden semantic and syntax.

> 
> if standard jsf xhtml files are to have problems with the JS Formatter then I
> think this is a big problem.
Standard jsf/xhtml/javascript/some_other_technology just allows you to do even ugly things. This sample is one of such things imo. From the IDe point of view you can be either very conservative but not really helpful or you may optimize and help the majority of typical usecases. Obviously as nobody from our users reported this in years it is not a real problem.

what do you mean no one reported the problem in years ?

the problem first appeared in the netbeans edition it was reported in - not in a previous version of netbeans.

(In reply to comment #11)
> what do you mean no one reported the problem in years ?
> 
> the problem first appeared in the netbeans edition it was reported in - not in
> a previous version of netbeans.
These attributes has always been considered as JS so there was always JS lexical and semantic coloring, code completion, code templates, indentation etc. The issue is not in a formatter. The issue is that these attributes are assumed to be JS which seems to be ok in 99% of cases. If we would give up because in rare case it is not JS we would break functionality for that majority. Does not seem to be reasonable.

Marku do you see any solution?

The big confusion for me - I don't know JS - is that the JS Formatter is 'expanding' quoted strings -- something like "xxxx/yyyy" becomes "xxxx / yyyy" - I don't know why JSFormater would want to do this ?

JSF - the issue is with JSF xhtml pages -- JSF takes the initial xhtml as a template and re-writes the xhtml page when it is served up back to the user -- and also adds it's own JavaScript to the page.

-Gary

(In reply to comment #13)
> The big confusion for me - I don't know JS - is that the JS Formatter is
> 'expanding' quoted strings -- something like "xxxx/yyyy" becomes "xxxx / yyyy"
> - I don't know why JSFormater would want to do this ?

In (x)html the attributes onmouseclick, onmouseover and similar are handled as javascript fragments (similar when you have <script>foo;</script>) and as such at that fragments of the document javascript features apply. There is no expanding. Just plain old javascript - so if there is "foo/bar" it is effectively javascript fragment telling foo divided by bar. And when formatted spaces are placed around binary operator division.

However in your case the component seems to use onmouseover as an attribute for image path. It would be better if the attribute has different name than the "standard" one, for example imageonmouseover.

BTW for your particular case it would help to disable spaces around binary operator (Tools/Options/Editor/Formatting/JavaScript).

I don't think we can detect the case.

Your hint about javascript formatting options seems to be a solution.

I do configure the java formatter but did not think to look for javascript options.

This issue as far as i have discovered is purely one where a path with '/' is interpreted as binary operator.

Thanks

I believe the assumption that onXXX attributes have javascript content is bearable as vast majority of users do put javascript into them. As Petr said, not 100% correct, but IMO satisfactory. As far as I know no one so far complained about that. 

OTOH I understand that it is a problem that the code becomes broken by the JS formatter. 

Couldn't be the simplest solution of this problem to simply not format the javascript code from such onXXX attributes? I believe the JSEmbeddingProvider can simply put some marks to the generated embedded js code preventing the formatter to format the content? Sg. like /** onXXX> **/ embeeded code for the attribute /** <onXXX **/? Wouldn't it be too complicated to adjust the formatter Petre? In theory we can come up with some much more heavyweight solution, but this simply fixes the bug, nothing more :-)

Please return to me if the proposal is not to your liking.