Deployment mappings, PHP Server mappings, and JS Remote mappings, oh my

It feels to me that a some refactoring is needed around servers and mappings...

For JS, debug mappings are defined at the JavaScript Debug Remote configuration level (attachment mwsnap120.png).

This  seems to differ from the PHP approach where the user defines PHP/Servers  at the project level (javascript:; and see attachment mwsnap121.png). Then the user can choose between PHP Servers in the PHP On Server configuration (see attachment mwsnap122.png). I'll add you can choose mapping overrides if  necessary.

Then on top of those, for both PHP and JS there are also Deployment Server configurations that also indicate mappings (see attachment mwsnap123.png). And the default Deployment Server Configuration is used to determine Preview URL (javascript:;). I'll add, it would nevr of occurred to me to look under Deployment to change the Preview path if I hadn't seen it in the forum.

I've created an issue to change JavaScript Debug Remote to work like PHP On Server with PHP/Servers (http://youtrack.jetbrains.net/issue/WI-4761).

But now I am thinking a some refactoring is needed between Deployment Server Configurations and PHP/Servers. My first though is that there should be a top-level item called just Servers, and that servers have deployment, debugging, and other aspects (perhaps in tabs). That seems more natural. Like with Deployment, you can choose a default Server and it will be the default for Preview, Run, Debug, and Deployment unless you override it in their specific configurations.

d



Attachment(s):
mwsnap123.png
mwsnap122.png
mwsnap121.png
mwsnap120.png
6 comments
Comment actions Permalink

We recogenise the usability problems in this area and plan to work on them later.
Right now we're focused on getting both debugger and deployment work properly and be feature-complete.

0
Comment actions Permalink

neuro159 wrote:

We recogenise the usability problems in this area and plan to work on them later.
Right now we're focused on getting both debugger and deployment work properly and be feature-complete.


I agree that should be the top goal, thought it might be interesting to spark a user conversation in the meantime about what they would like to see. Including the PHP folks since they have related but different needs

d

0
Comment actions Permalink

I like the "default" server approach. I mean, why have different server settings for js and php? Can't they use the same settings? If you are using PHPStorm its safe to assume you are writing PHP, HTML, Smarty (maybe) and JS. Right?

0
Comment actions Permalink

I'm a PHP and web programmer and new to using an IDE.  I've used Dreamweaver for ten years.  Setting up PHP servers and mappings in PhpStorm is very confusing, especially on Windows.

I'm probably somewhat representative of the US php developer community-- I lack formal computer science training but have good experience.  That is a major difference between php and the Java market-- almost all Java developers have formal programming education and understand what an IDE is trying to do, whereas most php developers come to this from learning on the job and probably don't use an IDE so a lot of the menu options are unfamiliar.  

Obviously, getting local php up and running properly is more important to the newer user since so many advanced features depend on that.  

It is also difficult to set up the project paths for first time users.

Overall, I really like PhpStorm and I am spending a lot of time trying to learn it, and the documentation is generally excellent.  Thank you!

0
Comment actions Permalink

Actually, to further show that Deployment does a lot more than one would expect. It seems the presence of a default Deployment Server changes what the default HTML JS debug action is (when you select a HTML file and just chose Debug (without selecting a specific debug configuration).

If you have a default Deployment Server defined, then it assumes JavaScript Local.

If you do have a default Deployment Server, then it assumes remote and will even use the Deployment Server mappings to open the right file.

However, for the default remote WS then raises an error that debugging will not work (see attached image) because the file doesn’t have a Remote URL defined. Looking at the generated debug configuration (see 2nd attached image), I can see that the “URL to open” is populated from the Deployment Server mappings, but the “Remote URLs of local files isn’t”.

I would suggest an initial fix would be to at least populate Remote URL also when creating a new debug config. This would cause remote debug mapping to work ok, assuming the user knows to create a Deployment Server. I’ve added this to http://youtrack.jetbrains.net/issue/WI-4761.

d


PS, As an FYI for others, Deployment Servers seem to be shared across projects even though they are listed under Project Settings. I think what is really happening is the Deployment Servers and their Connection tabs are IDE Settings, while their mappings (including if it’s the default) are Project Settings.

PSS, Since having a default Deployment Server changes the launch URLs for preview and debugging is done, it should be possible to un-default a Deployment Server. Right now when you first define a Deployment Servers it is made the default for the current project and there is no way to turn this off. So in order for me to do local debugging (without creating a custom configuration for each HTML file) I have to delete the Deployment Server. Interesting, if I switch to another project, that Deployment Server is not the default there. So it’s possible to not have any default Deployment Server – the GUI just doesn’t allow it. I went ahead and created issue http://youtrack.jetbrains.net/issue/WI-4935 for this.



Attachment(s):
mwsnap143.png
mwsnap144.png
0
Comment actions Permalink

@Stephen/@ChrisK0, after working through a few changes its become pretty clear to me that, at least during the EAP, the development team is more focused on items in youtrack than this forum (hence the comment across the top of the forum). So I recommened you vote for the issues you care about and make comments on them there rather than or in addition to here. You can vote for an issue by clicking on the number (not the star), and you can get updates by clicking on the binoculars to the right of the number. The main issue for this one is at http://youtrack.jetbrains.net/issue/WI-4761.

0

Please sign in to leave a comment.