Community
Participate
Working Groups
Build Identifier: Eclipse: 20100218-1602, PDT (SDK): 2.1.1v20090707-1108, PDT: 2.1.3v20090914-1400 (Eclipse EPP PHP Package) AND Eclipse: 3.5.2, build: M20100211-1343, PDT (SDK): 2.1.1v20090707-1108, PDT: 2.1.3v20090914-1400 Image the following project outline (just some top level folders): - src - js - templates - images - css Now under src there are my php files. I added src to my "Source" Folders in the project properties. When I turn on the setting "group by namespaces", my top level representation changes to this: - namespace\one - namespace\two - namespace\tree - ... I can only access my php files, all others are hidden. Instead, please just group the namespaces, that are in a "Source" folder recognized by the project properties dialog. According to the example above, this would be: - src -- namespace\one -- namespace\two -- namespace\trhee - js - templates - images - css So I am able to access other files of my project, while I have a namespace concentrated view on my php files. At the moment, the "group by namespace" setting is totally unusable. Keep in mind, less projects are working with php files only. A little other thing: Wouldn't be the "package" icon more suitable, instead of the big, fat, green N which pulls every attention from the user, it could get, everytime? For me this would lead to a more consistent UI overall. Reproducible: Always
add something to here: "A little other thing: Wouldn't be the "package" icon more suitable, instead of the big, fat, green N which pulls every attention from the user, it could get, everytime? For me this would lead to a more consistent UI overall." ... or probably the package icon with a "P" or a "P" with the package icon or any other combination. For the UI consistentency: other source editing plugins like Java or JavaScript also use the package icon, this is where my thought was coming from.
Hi Roy Can you make decision for the "group by namespaces" structure and the namespace image?
At the moment, the group by namespace option removes the source folder the project explorer and adds all found namespaces to the root level. I'd suggest a similar option as this is in java. Like grouping the namespaces under the source folders. Something like this: - source folder -- Name\space --- MyClass --- MyInterface -- Another\Name\Space --- MyClass --- MyInterface - source folder 2 -- <global> --- getStuff() -- second\name\space --- MyClass - other - folders - in - my - project
I want refresh this task. I implemented grouping by source paths, to make "grouping by namespace" more usable for larger projects. But this function is still have some bugs: 1. Resources are still hidden 2. Namespaces doesn't refresh during developing 3. Link to editor not work Besides, scrolling in explorer on large projects can be painfull ;) Due php dynamic nature, I think we should make PHP Explorer (and maybe project layout settings) more extendable. Example use cases/problems: * PSR-0 and PSR-4 grouping * Grouping per module for Symfony, Drupal, Kohana, Zend or Magento projects * Resources (html,css,yaml..) inside buildpath PHPExplorerContentProvider extension should: * Report grouping type (unknown, none, namespace or custom) on IContainer * Deliver custom elements, if any * Deliver label provider for custom elements Thoughts?
Yes! I opened an issue for the composer-plugin lately: https://github.com/pulse00/Composer-Eclipse-Plugin/issues/110 which actually refers to this bug ;) I think the biggest issue for PDT itself is the missing metadata, that plugins can provide. The other is a little more research on where and how a possible grouping can be done within the php explorer. Some frameworks (I think zend, however I never used and worked with it) has the application folder + some folders for models, views and controllers. Other frameworks have different folder structures. It would be great to give framework plugin authors a possibility to easily tweak the php explorer view and highlight them. Also what would be nice, is to say, ok this project is a symfony/zend whatever project (from a plugin perspective). Like a good way to extend php projects (maybe Facets is a solution, I don't know that technic well enough). Maybe discuss it at a larger scale? PDT/PEX mailing list - this is also where PDT plugin authors are.
PEX mailing list can be used to send invitation to this bug. Each feature request could be helpful while developing api, I have experience only with several frameworks/systems. PHP-Fi memebers? From Symfony 2 side, we need ability to report bundles (modules) and resources (configs, doc, public, i18n, and more).
I think its about finding general patterns that are used across different frameworks. Those that come to my mind: - Decorations: 'custom' folders and projects - Specific operations on these 'custom' folders and projects - Modifying source path entries in the php explorer (https://github.com/pulse00/Composer-Eclipse-Plugin/issues/110) - Tools-Support: Installed via Composer (https://github.com/pulse00/Composer-Eclipse-Plugin/issues/105) or CLI respectively (Using Apache Commons to execute them, currently in PEX, I extracted them to https://github.com/gossi/eclipse-components - Specific PHP Project operations (decorations, tools) While a lot is already covered through eclipse APIs. PEX mailing list and PHP-FI are surely worth a try.
I recently retried this in pdt 3.5 - I guess this can be closed? just by its original idea. However discussion led somewhere else towards the end.
This is an old bug of mine which is fixed in recent PDT version. I'm happy to close this.
It's still not fixed. Resources aren't hidden if are outside build, or are part of first level in build path. Example: app/ src/ AppBundle/ Controller/ Resources/ If you set buildpath to src/, resources from src/AppBundle/Resources aren't available.
Awww, what a pity. I reopened this one. Maybe I also found another one, which kinda is related. Example: src/ res/ tests/ fixtures/ FooBar.php ControllerTest.php If group by namespaces is on, even stuff in tests/fixtures/ is shown, which basically is totally unrelated to my code. Maybe there should be something like exceptions on source folders, which are both automatically detected but also manually selectable?