Re: PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling) - Mailing list pgadmin-hackers
Hi Dave/Ronan,
On Mon, Apr 20, 2015 at 4:10 PM, Dave Page <dpage@pgadmin.org> wrote:
On Mon, Apr 20, 2015 at 10:52 AM, Ronan Dunklau
<ronan.dunklau@dalibo.com> wrote:
>> Ronan; can you update the test, help and about modules as well please?
>
> Done, please find attached a new patch for that. Ashesh, once you're done with
> what you are doing now, feel free to ask me for any help needed to integrate
> this after the fact.
Thanks.
Thanks - It looks good to me.
(And, attached patch is based on that.)
>> > snippets of javsacript generated by the server. I feel like this apporach
>> > is extremely fragile. Even before the patch, most of the tree actions
>> > were not working properly.
>>
>> That's odd - they all worked for me
>
> Adding a server is not functional, as well as adding a server group.
Server groups should be fully functional. Adding a server isn't -
that's what Ashesh is investigating backbone.js for.
It is now fully functional as it was earlier with the attached patch.
I am still working on the backbone.js.
I am trying to make it general, so that - we can fit it in both properties pane, and dialog both together.
In order to achieve, I have made a class NodeView (inherited from flask's view), just like the MethodView.
Flask's MethodView is good to achieve CRUD functionality.
Browser Tree Node (PostgreSQL object) requires more than just CRUD.
i.e.
i.e.
- CRUD (Create, Read, Update & Delete)
- Reversed Engineered SQL for the object
- Modified Query in edit mode
i.e. ALTER TABLE ...
- Statistics
- List of dependents
- List of dependencies
- Modified Query in edit mode
i.e. ALTER TABLE ...
- Statistics
- List of dependents
- List of dependencies
- Children node list
This class can be inherited to achieve the different routes for each of the object types/collections.
OPERATION | URL | Method
---------------+------------------------+--------
List | /obj/[Parent URL]/ | GET
Properties | /obj/[Parent URL]/id | GET
Create | /obj/[Parent URL]/ | POST
Delete | /obj/[Parent URL]/id | DELETE
Update | /obj/[Parent URL]/id | PUT
SQL (Reversed | /sql/[Parent URL]/id | GET
Engineering) |
SQL (Modified | /sql/[Parent URL]/id | POST
Properties) |
Statistics | /stats/[Parent URL]/id | GET
Dependencies | /deps/[Parent URL]/id | GET
Dependents | /deps/[Parent URL]/id | POST
Children Nodes | /nodes/[Parent URL]/id | GET
NOTE:
Parent URL can be seen as the path to identify the particular node.
i.e.
In order to identify the TABLE object, we requires information about the server -> database -> schema objects.
This class can be inherited to achieve the different routes for each of the object types/collections.
OPERATION | URL | Method
---------------+------------------------+--------
List | /obj/[Parent URL]/ | GET
Properties | /obj/[Parent URL]/id | GET
Create | /obj/[Parent URL]/ | POST
Delete | /obj/[Parent URL]/id | DELETE
Update | /obj/[Parent URL]/id | PUT
SQL (Reversed | /sql/[Parent URL]/id | GET
Engineering) |
SQL (Modified | /sql/[Parent URL]/id | POST
Properties) |
Statistics | /stats/[Parent URL]/id | GET
Dependencies | /deps/[Parent URL]/id | GET
Dependents | /deps/[Parent URL]/id | POST
Children Nodes | /nodes/[Parent URL]/id | GET
NOTE:
Parent URL can be seen as the path to identify the particular node.
i.e.
In order to identify the TABLE object, we requires information about the server -> database -> schema objects.
Hence, the Parent URL for the TABLE object will be something like this as below:
<int:sid>/<str:database>/<str:schema>
<int:sid>/<str:database>/<str:schema>
I already did that for ServerGroup, and Server nodes.
Attached patch is still in work in progress, and based on Ranon's latest patch.
(So - in order to apply my patch, you should apply Ronan's latest patch first, and then mine.)
>> > noticed) feel once again not really robust. All this widget assembly is
>> > done "ad-hoc".
>>
>> How would you expect it to be done?
>
> In my opinion, it should either be done by using a set of widgets already
> designed to work together (think of wxwidgets, but for the web), using one of
> the frameworks I mentioned before. Or alternatively, by developing the glue
> between those widgets ourselves, using something like Backbone to wrap those
> libraries into nice views able to play together.
The problem is that I haven't found any OSS frameworks that provide
anything like the capabilities we have by using ad-hoc components.
There is nothing at all that comes close to the functionality (and
look/feel) of wcDocker, CodeMirror, AlertifyJS and aciTree that I've
found, let alone in a single framework. I've spent a *lot* of time
researching that, and trying to find components that give us what
we're going to need.
> +1 for that. As for the extensibility, how is it expected for someone to
> provide a plugin ? Should he write a module that is supposed to be installed
> in the pgadmin directory directly ? Using the modular approach proposed by
> distutils/setuptools ? Plugins seems to be installed into the pgadmin package
> directly, which is maybe not the most convenient way to manage third-party
> modules.
The current plugin mechanism is documented, but the basic premise is
that you can add a new module or node by dropping a Python package in
the right directory, without having to edit any configuration or code.
That is particularly important for tree nodes where the directory
structure is used to define the tree structure, to avoid having parent
nodes needing to have any pre-knowledge of what their children will
be.
If you have better ideas of how to do that, I'm happy to hear them. I
do need to avoid long, drawn out discussions and rewrites though; I
can only justify putting significant EDB resources into the project if
we continue to move forwards at a reasonable speed.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachment
pgadmin-hackers by date: