Idea for getting rid of the bundle #2
Comments
|
Thanks! :) I was hoping I wouldn't have to do this all by myself. Losing the bundle would be an advantage. Less complexity is always good, but I am unsure of what approach would enable us to do this. @lolautruche hoped for something like this plugin to surface some time ago. His approach was to create the legacy equivalent of a bundle: an extension. He may correct me on this, but I suspect that his choice was thought through. I only chose the bundle-approach, because it was the fastest way to get started. The current approach does have some advantages that the Symfony-plugin does not provide. If the development environment is remote, PhpStorm will login through ssh and fetch the completions directly via the configured remote interpreter. In time I hope to eliminate the need for a separate ssh-session in terminal alltogether. I did consider adding an auto-install feature for the bundle, but supporting this for remote environments as well, pose some challenges I have postponed for now. The current implementation isn't too brittle. The container just have to work at some point. The completions are fetched asynchronously and cached in the plugin for fast retrieval. Should the site not be loadable on startup, completions can be refreshed at any time. If this turns out to be a big issue, I could also make PhpStorm persist completions permanently. I have yet to look into the rest-api. Could it be of service perhaps? Short of getting the bundle included in the eZ Publish platform, I have no idea on how to lose it. I am of course open for suggestions. The current feature I'm working on will allow the user to actually execute queries using the SearchService. Data will be returned along with some basic info regarding query-performance. For this to work, some custom PHP-code is required. Hmm... perhaps we are overthinking this. What if I just "bundle the bundle" along with the plugin? Do you know if composer would get angry if I just snuck in a symlink on plugin-install? |
I don't think it's a problem if it doesn't work on remote in all cases right now. It's a very nice feature, but it's also a bonus. As long as the bundle can be manually installed, there is an accessible workaround. Note that using the container would work on a remote system. Of course, it requires that the compiled container is downloaded, but it's a one time thing.
Yes, it could. I'd even say it's the "ideal" way to do it for remote systems. But ideal with quotes, as I don't think it is optimal in that case. It's a cleaner interface, but it's also more restrictive, and relying on it would I think slow things down. I'd keep it in mind for later, as a beacon.
That's really, really cool. Do you have a spec, even if very informal, that I could read ? ;-)
You could symlink it to src to prevent composer from caring. But this wouldn't work when working with the code in a VM, accessed over samba ;-) Now about the container thing... What we could do is add a few compiler passes to the DebugBundle. They would:
The plugin could then read those variables, and use them for completion. It is exactly what the Symfony2 plugin does. The drawback is that it requires a recompilation of the container when something is changed that affects completion. But that aside, it's really fast and reliable. And while I'm at it, it kinda connects to this query builder thing I've been working on. I intend to compile "repository properties" usable in search, and compile the QueryBuilder's API based on that. We could probably work something out that works for both projects (and hopefully more). Oh... one more thing :p About the drawback mentioned below, the container requiring to be recompiled when something changes... if we have such a repository properties compiler, we could add a couple event listeners that invalidate the container when relevant events happen (add/remove content type, etc). It would slow things down of course, but there are benefits for the developer, I think. It could also be made optional ? One trick we could use for this would be to update a value (timestamp) in a writeable (custom) parameters.yml file. The content change would rebuild the container upon the next call (iirc). So... any thought ? :-) |
|
Gathering all the data in the compiled xml-container-file file sounds like a good solution to me. Especially since we both need the data. Hopefully we can agree on a format which is easily deserializable in Java! :P Some automatic invalidation sounds like a good idea. I don't think the required data changes often enough to warrant an option for this, but If we add one, I suggest we make default-on the dev-environment. Using a custom yml-file to cause invalidation is probably not the best approach. There is a .meta-file in the cache-folder which contains a list of files. Simply touching one of them (updating the timestamp) will cause the container to be recompiled. ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishDebugBundle/DependencyInjection/EzPublishDebugExtension.php seems like a likely candidate. |
|
meta file does sound much cleaner :) Isn't the Sf2 plugin opensource ? it already has quite a rich parser, imho. |
|
The query-executor it is very much a work in progress. For now I'm trying to isolate all the code required to build and execute the query. This is the hard part. There is also the posibility that some developer puts some destructive code in there, but for now that is their own resposibility! :) I have created an intention which will be made available while the cursor is placed within the "findContent" method. Invoking the intention will ship along the aforementioned code together with the name of the variable which is assigned the result. I will then eval the code in and sneak out the data I wish to present. Hopefully the presentation won't be unlike the one xDebug uses. |
|
It is indeed open-source. I have tried to draw inspiration from it, but it is a big plugin. Also the Java-skills and knowledge of the Intellij-internals of Haenchen, is way beyond me right now! :) |
|
Where in the container do you think we should put the additional data? I think the Symfony2 plugin is only parsing what is already there. Unless you can think of a reason, we probably shouldn't pollute the parameter-section. It is however possible to put custom bundle-configuration into a separate namespace. |
|
I'm not shocked by repo data as container parameters, as long as it can be toggled. How big are we talking about here ? What kind of info do you need about queries ? |
|
It is rather verbose at the moment. My PHP-skills far exceed my Java-skills, so all data-parsing is done in PHP. For a moderate installation the generated json consists of 7200 lines! :) The data itself is of course nothing near this. For queries I intend to return the actual results and how long it took. |
First, thank you very much for your work on this plugin. It's really cool that somebody got this started, and I'm sure we can kick it much, much higher together :-)
I think that we could get rid of the bundle's requirement. It is used as far as I could see to read what's in the repository (fieldtypes, languages...). But there are a couple drawbacks to this approach, among which a requirement of a working container. Configuration mistakes will break the script, unless I'm mistaken, and they're much more common while editing the said config.
But we could do what is done by the PhpStorm Sf2 plugin, and use the compiled container's static file. Of course, this information isn't here yet, but we could quite easily add it with a set of compiler passes.
It would also make it to setup the plugin, as it would work right after download.
Thinking about it, it would also require an extra bundle, unless we manage to find a solution suitable for kernel / native inclusion. If this container data could be used by other components, it would make it much more likely.
What do you think ?
The text was updated successfully, but these errors were encountered: