Case 1 (resp Case 2) is caused by the fact that text/x-jsp (resp. text/x-php5) is not a MIME type supported by CssStylesTCController.

Case 4 is caused by unsuccessful matching of the opened file index.xhtml with the URL opened in the browser. In other words, the root of this case is that ServerURLMapping.fromServer(project, "http://localhost:8080/WebApplication3/faces/index.xhtml") returns null (note the 'faces' directory in the URL).

Wrt. Case 4 - sounds like this may need to be fixed on the side of web project or JSF framework, cc'ing David and Martin.

> Case 1 (resp Case 2) is caused by the fact that text/x-jsp (resp. text/x-php5)
> is not a MIME type supported by CssStylesTCController.

I have added JSP and PHP files among the files supported by CSS Styles view and its Selection tab. Hence, CSS Styles view is opened whenever JSP or PHP file is opened and it shows the Selection tab (i.e., the 'Run' button when the opened file is not executed in a browser with NetBeans integration).

Modified files: http://hg.netbeans.org/web-main/rev/eedff2058f80

(In reply to comment #2)
> Wrt. Case 4 - sounds like this may need to be fixed on the side of web project
> or JSF framework, cc'ing David and Martin.

AFAIK, WebFrameworkProvider is capable to return relative URI to run for given file thru the #getServletPath() method. I don't know easel needs but from the #fromServer() method it looks to me that we will need the opposite access.

From my point of view we will need improve Web APIs WebFrameworkProvider to be capable to return FileObject for the given URL or JSF probably could register into the project lookup its own implemenation of the ServerURLMappingImplementation using @LookupProvider.Registration.

But my candidate is API extension since it's more straightforward to another frameworks (clients) and what I heard @LookupProvider.Registration is probably nothing we would like to build upon. What do you think Davide?

Case 3 is similar to Case 4, i.e., its root is in an unsuccessful matching of the opened file index.html with the URL opened in the browser. The failure in matching is more subtle than in Case 3. The URL opened in the browser is something like http://localhost:8080/WebApplication4/ and the FileObject returned by ServerURLMapping.fromServer(project,url) is <root folder of Web project>/web.

Note that this happens when the project is executed only. When you run the index.html file directly then the opened URL is something like http://localhost:8080/WebApplication4/index.html and the FileObject returned by ServerURLMapping is <root folder of Web project>/web/index.html (which matches the file opened in the editor).

There is a similar problem when the PHP project is executed.

Thanks Honzo for the investigation and partial fix. 

So basically the problem for all 4 cases is now the implementation of ServerURLMapping, that should be improved in Java Ant web project, Java Maven web project and PHP project. Assigning to Java web project for now.

Martin, not sure to what extent we would want to address frameworks - this is probably impossible to do in general, see also David's planning page: 
http://wiki.netbeans.org/EaselInOtherProjects#Scenario_4_-_server_side_templating.2C_eg._JSF.2C_JSP.2C_PHP.2C_etc.
I can imagine an analogous problem will arise for PHP frameworks, cc'ing Tomas and Ondra.

One other question is whether we want to enable CSS Styles window for more kinds of files (in addition to JSP and PHP that Honza just added) - what about things like Twig and Smarty? Again, a question for the PHP team.

(In reply to comment #7)
> Martin, not sure to what extent we would want to address frameworks - this is
> probably impossible to do in general, see also David's planning page: 
> http://wiki.netbeans.org/EaselInOtherProjects#Scenario_4_-_server_side_templating.2C_eg._JSF.2C_JSP.2C_PHP.2C_etc.

Agree that there is no chance to implement such mapping for many cases and probably only the basic ones we could be able to cover. At least I thought that some kind of specific heuristic (per included framework) could try its best and return file/files when possible. On the other hand not reliable solutions will be confusing to users. :/

I have a fix for both this issue and issue 226386 but I would like to test it a bit more before pushing it. Should be in main repo early next week. The ServerURLMappingImplementation impl was enhanced to read welcome-file-list from web.xml (or using default values if web.xml is missing as specified in the Servlet spec) and it also reads all servlet mappings from web.xml which has pattern defined as "/somepath/*" and uses that pattern to translate server URLs to project source files (for example in JSF case default mapping is /faces/*). It seems to work quite well so far.

web-main#6e18240fcf97
I will push the change to web-main later today.

MartinJ, Maven will probably need very similar code, right? I'm happy to refactor and move most of my commit into web.common module if it would help you. Just let me know. Or, if you prefer, refactor it yourself to you liking.

In PHP, we already have implmenetation of ServerURLMappingImplementation so I guess this should already work for us? Let me know if I am wrong, thanks.

Integrated into 'main-golden', will be available in build *201302252300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/6e18240fcf97
User: David Konecny <dkonecny@netbeans.org>
Log: #226383 - CSS styles window is not populated correctly for JSP, PHP, Facelets, ...

> Maven will probably need very similar code

Reopening and assigning to Maven.

> In PHP, we already have implmenetation of ServerURLMappingImplementation so I
> guess this should already work for us?

Well, not necessarily. Ideally this implementation should take frameworks into account - the question is how far we want to go. Tomas, please test Case 2 and maybe some other cases involving frameworks, and file separate bugs if necessary.

(In reply to comment #13)
> Tomas, please test Case 2 and
> maybe some other cases involving frameworks, and file separate bugs if
> necessary.

Láďo, could you please do it? So we can then easily verify...

Thanks a lot.

I started IDE with fresh user dir and created new PHP project:
- CSS Styles is opened together with PHP file
- it offers to run the php file (as Honza described in comment #3)
- if I turn inspect mode on and select element in browser, CSS Styles window is correctly populated (again only Selection view is available)

I tried "plain" PHP project, Symfony1/Symfony2, Zend1/2 and Smarty project (file to run in all projects was php/phtml). The only issue I found is minor issue 226965


Product Version: NetBeans IDE Dev (Build web-main-10012-on-20130304)
Java: 1.7.0_15; Java HotSpot(TM) Client VM 23.7-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_15-b03
System: Linux version 3.2.0-38-generic-pae running on i386; UTF-8; en_US (nb)

Thanks a lot Láďo!

You'r welcome, no problem.

I noticed Honza's comment #6 and this is still issue with PHP. If you run project without specifying index file, so http://localhost/project, then only Rule Editor part of CSS Styles works, but the upper part still offers to run some PHP file.

When I tried in the latest build, navigator does not work well for me, I filed bug 227168 for that (for JSP files). I suspect the same issue will be there for PHP, JSF, ...

However, the fact that this behaves incorrectly is not surprising considering the implementation.

Maven implementation done in:

web-main #96f0f0f36135
web-main #51e971fb614d

Integrated into 'main-golden', will be available in build *201303122300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/96f0f0f36135
User: Martin Janicek <mjanicek@netbeans.org>
Log: #226383 - CSS styles window is not populated correctly for JSP, PHP, Facelets, ...

Btw: The refactoring to the web.common isn't much straightforward because there already exists a dependency from web.browser.api --> web.common and it would caused cyclic dependencies problem. Although it uses only few helper methods:

DependentFileQuery.isDependent()
WebUtils.stringToUrl()
ServerURLMapping.fromServer()

..all three of them created by you. I'm not really sure if it is possible to move them directly to the web.browser.api module (so we could get rid of the current dependency) or whether there is a need to use them also in some other modules. Could you take a look at it?

(In reply to comment #10)
> MartinJ, Maven will probably need very similar code, right? I'm happy to
> refactor and move most of my commit into web.common module if it would help
> you. Just let me know. Or, if you prefer, refactor it yourself to you liking.

I think David meant something like j2ee.common, not web.common. Because this code is Java-specific so it needs to be in the enterprise cluster, while web.common is generic and Java-independent, and is in the ide cluster. So the question is, could this code be shared via j2ee.common or some other module in the enterprise cluster?

Created attachment 132922 [details]
Merging the Ant+Maven implementations

Today I found an additional bug 227790 in this area. Given the fact that the implementation of the algorithm is copy/pasted in Ant and Maven project, I really think we should try to merge them back. I am attaching a patch that does that. David or Martin, can you please review? Thanks.

[Tomas Mysik - please read :-) ]

The refactoring makes sense. Thanks. The patch looks OK apart from one subtle think: getBrowserSupport() method in web.project has

WebBrowser browser = WebBrowserSupport.getBrowser(selectedBrowser);
if (selectedBrowser == null || browser == null) {
    browserSupport = null;
}

and maven version does only

WebBrowser browser = WebBrowserSupport.getBrowser(selectedBrowser);
if (browser == null) {
    browserSupport = null;
}

Calling "WebBrowserSupport.getBrowser(null)" will return "Chrome with NB integration" which means that any existing project without explicitly selected browser will have "Chrome with NB integration" which I wanted to avoid in Java Web project. And likely Maven project wants to do the same. I must admit that I find WebBrowserSupport.getBrowser(null) behaviour not intuitive but that's how TomasM designed it and I got used to it now. We can change it if there is more interest in it but PHP project would need to be updated.

In order to fix 227790 this patch needs to be applied first. To avoid more work.

[David Konecny - please read :) ]

(In reply to comment #24)
> Calling "WebBrowserSupport.getBrowser(null)" will return "Chrome with NB
> integration" which means that any existing project without explicitly selected
> browser will have "Chrome with NB integration" which I wanted to avoid in Java
> Web project. And likely Maven project wants to do the same. I must admit that I
> find WebBrowserSupport.getBrowser(null) behaviour not intuitive but that's how
> TomasM designed it and I got used to it now. We can change it if there is more
> interest in it but PHP project would need to be updated.

Not really true - yes, I made it but please notice that the original behavior was the same as you say, it means: use the default browser from IDE options. BUT later (issue 219542#c16 [1]) I changed it based on feedback from PetrJ - the integration would be hard to discover - that is true. So the current plan - AFAIK - is to prefer any external browser with NB integration. If the feedback will be negative or we will be able to find a better way to "promote" Easel support in other project types, we will easily change it in _one_ place. Therefore I really think that the behaviour should be same in _all_ project types so we are consistent.

Thanks.
[1] http://hg.netbeans.org/web-main/rev/8b391821da00

(In reply to comment #23)
> Created attachment 132922 [details]
> Merging the Ant+Maven implementations
> 
> Today I found an additional bug 227790 in this area. Given the fact that the
> implementation of the algorithm is copy/pasted in Ant and Maven project, I
> really think we should try to merge them back. I am attaching a patch that does
> that. David or Martin, can you please review? Thanks.

The patch looks fine to me.

> getBrowserSupport() method in web.project has ... and maven version does only ...

I noticed this, wasn't sure why that was. So at the end I added the extra condition selectedBrowser == null, I agree the behavior should be consistent between Ant and Maven.

> feedback from PetrJ - the integration would be hard to discover

Yes, but I think the main solution to that should be to add the browser selection in the toolbar, which is in progress. So now I don't feel very strongly about which browser should be the default.

I pushed the patch: http://hg.netbeans.org/web-main/rev/a73972e812cf

(In reply to comment #28)
> Yes, but I think the main solution to that should be to add the browser
> selection in the toolbar, which is in progress. So now I don't feel very
> strongly about which browser should be the default.

I agree, of course. Another reason why to be consistent, at least for now.

Thanks.

Integrated into 'main-golden', will be available in build *201303222300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/a73972e812cf
User: Petr Jiricka <pjiricka@netbeans.org>
Log: #226383 - additional change to merge the implementations for Ant and Maven.

"Chrome with NB integration" being a default browser for Java Web was disaster - it happened by accident for few days in nightly builds and we immediately got a few bugs. The browser switcher in main toolbar may help.

If consistency between all project types is what is desired then we should change the behaviour of this API method to return "IDE's default browser" and update Java Web/Maven to call only

WebBrowser browser = WebBrowserSupport.getBrowser(selectedBrowser);
if (browser == null) {
    browserSupport = null;
}