I thought about reversing the process by having Rapid open the project and launch EW. This is more inconvenient than I hoped but it is not a complaint about Rapid it also applies to the other tools I evaluated. In practice this means that I must open a project in both EW and Rapid. I had hoped to have EW control the project but unless Rapid opens the project, Rapid cannot "see" the entire project and thus understand the scope of the code. It cannot tell the editor to open a folder or a project. The limitation of this useful EW feature is that it can only tell an external editor to open one file. (For testing I also added Atom, NotePad++, VSC, PhpStorm and others.) It was thus simplicity itself to add Rapid PHP to the list of editors for PHP files. The developers chose to make the feature generic, meaning that any file type can be associated with an external editor. This feature has been very handy all along for graphics files, which I happen to think is the original reason the feature was created. In most cases the editor is internal to EW. Project ManagementĮxpression Web (and before it FrontPage) has the ability to specify which editor should be used for a given file type. Let's start by revisiting my key features list and seeing how Rapid PHP ("Rapid") addresses them. Otherwise, I would have been a fool to choose it. A key assumption should be that as an editor Rapid PHP meets my needs. It will not be comprehensive, examining every aspect of its capabilities and stating judgements. It is a review because I will describe Rapid's features and how it applies to my situation, calling out both the good and the bad. The rest of this article will focus on why I was willing to commit to Rapid PHP. After editing with both for reasonable amounts of time, I decided to do a deeper dive into Rapid PHP and ultimately decided that it was more than adequate for my situation. I was doing useful work faster with Rapid PHP while still struggling with PhpStorm. While I'm confident that PhpStorm is not beyond my abilities, I like simple. It was also apparent that just getting PhpStorm going and properly configured was more complex. It became immediately apparent that PhpStorm is the superior product with more capability and features than Rapid PHP. I downloaded both for their respective evaluation periods (generous in both cases) and experimented with them both. I am also somewhat concerned about the future of plug-ins - will they be maintained as long as the parent tool and will they always be compatible? Because using the tools would have made Visual Studio the central tool, I decided not to bother. I considered looking at the two major PHP plug-ins for Visual Studio, VS.PHP and PHP Tools for Visual Studio. I use NotePad++ every day for general text editing and thus know it well but rejected it because of the lack of project management. I quickly rejected VSC and Atom because their project management capabilities did not jive with EW (or they didn't have project management at all). Visual Studio products do that but EW does not. EW has this but because EW is no longer maintained, its IntelliSense is not up to date with the latest versions of PHP and it is missing things from other languages as well.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |