-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backend decoupling #244
Backend decoupling #244
Conversation
No idea why Travis broke, looks like it might not be autoloading any class (I can run the tests successfully). |
Any news, guys? |
I did not want to mess up this branch code so I started my own attempt to separate UI from storage. I have a working branch with mongo, pdo and file operations (but only storage type at a time). I just need to find some time to finish that up and push. |
@GrzegorzDrozd The xhgui-collector part is ready. Do you want to finish the job here? (I would close this PR) |
No. I will create new PR. |
collector part is released now: https://github.com/perftools/xhgui-collector/releases/tag/1.7.0 you can omit 7435c57 commit |
I don't think 08cbb4e commit belongs to this PR. submit as separate PR if you intend to publish that change. |
No problem, that's just for me. I used to have my own, uncommited docker-compose.yml file in my local copy of the project. I'll revert that commit once the branch is ready. |
This branch is at a stage where the PDO integration is useful (or at least useful enough for my use case), which is:
The integration is still rough and incomplete though, but I am stretched thin. What I'd suggest is merging the branch and tagging a new release but saying that this feature is still experimental, then I'd break down the remaining work in small tasks so it can be done incrementally (by me as time allows or by whoever wants to do it). If anyone else wants to test the PDO integration themselves to assess the current status:
|
regarding merge technical aspect:
so therefore:
could do the rebase/squash/fixup myself too, but the PR creator has to allow maintainer pushes. not sure how to check is that on or off right now. |
I see the "Allow edits from maintainers" checkbox tickled, you mean that? |
yes, that checkbox. but you missed the original question :) |
There you go. |
merged. thanks! I might even test the result soonish. |
Backend Decoupling
PR implementing #234 (Work in Progress)
xhgui-collector change: perftools/xhgui-collector#11
Summary of changes
Xhgui_Profiles
was renamed toXhgui_Searcher_Mongo
and an interface (Xhgui_Searcher_Interface
) was extracted from it. Then I refactored the bits of the codebase that depended onXhgui_Profiles
to depend onXhgui_Searcher_Interface
instead, and started working on the newXhgui_Searcher_Pdo
. Finally, I tweaked the config and the DI container so that the user can choose which implementation to use when an HTTP request hits the app.Usage
In
config/config.default.php
there is a newpdo
key:The first three fields map to the arguments of the
PDO
constructor, and the fourth is the table where the profiles are stored. When the existingsave.handler
key is now set topdo
these values are used. So if you wanted to use an SQLite database, you'd copy the config toconfig/config.php
and put, for instance:Keep in mind that you need
xhgui-collector
to create these profiles, but the same new config applies to it.Pending work
Methods from
Xhgui_Searcher_Pdo
:Other
Xhgui_Seacher_Interface
implementation for each platform.