Re: PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling)

Hi Dave/Ronan,

On Mon, Apr 20, 2015 at 4:10 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Mon, Apr 20, 2015 at 10:52 AM, Ronan Dunklau
> <ronan(dot)dunklau(at)dalibo(dot)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.
- 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
- 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.
Hence, the Parent URL for the TABLE object will be something like this
as below:
<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.)

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company
<http://www.enterprisedb.com>

*http://www.linkedin.com/in/asheshvashi*
<http://www.linkedin.com/in/asheshvashi>

> >> > 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
>