PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling) - Mailing list pgadmin-hackers

Le vendredi 17 avril 2015 17:46:38 Dave Page a écrit :
> On Fri, Apr 17, 2015 at 12:55 PM, Ronan Dunklau
>
> <ronan.dunklau@dalibo.com> wrote:
> > Please find attached a WIP patch "reifying" the module API.
> >
> > The main browser/server_groups/server structure has been converted to his
> > API, whereas the test, help and about modules have not.
> >
> > The following changes were made:
> >  - instead of relying on a convention (views/hooks) for the module, each
> >
> > module should now inherit from PgAdminModule instead of the classical
> > Flask
> > BluePrint.
> >
> > This class brings several methods:
> >  -  get_own_stylesheets, which returns the stylesheets used by the module
> >
> > (excluding its submodules stylesheets)
> >
> >   - get_own_javascripts
> >   - menu_items, which returns a dictionray mapping the old hook names
> >
> > (context_items etc) to a list of MenuItem instances
> >
> > For more specialized modules (as for now, any module that should be part
> > of
> > the browser tree construction), one can define an abstract base class
> > defining additional methods.
> >
> > For example, the BrowserPluginModule abstract base class defines the
> > following>
> > methods:
> >    - jssnippets
> >    - csssnipeets
> >    - node_type
> >    - get_nodes
> >
> > Once again, for modules supposed to get included under the servergroup
> > modules, a new base class is declared, overloading the get_nodes method by
> > another taking a server_group as an argument.
>
> Thanks. Ashesh - I'll leave you to integrate this as I don't want to
> stomp on any work you're currently doing.
>
> 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.

>
> > Sorry for the wall of text, but...
> >
> > During the development of this patch, I encountered several things which
> > got>
> > me worried:
> >  - all the client-side interface building relies on global functions, and
> >  on
> >
> > 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.

>
> >  - the other downside of this approach is that the synchronisation between
> >
> > client and server state is done manually. It leads to hard to debug
> > errors,
> > where a node tree does not appear at the right place on the tree until the
> > whole page is reloaded
>
> Yeah, that is an issue.
>
> >  - the various components integration (docker, acitree are the main ones I
> >
> > 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 CRUD functionality should be abstracted away. There is no reason to
> >
> > declare  "add/rename/drop" menuentries, as well as their corresponding
> > enpoints manually. This is once again error-prone, and should prove to be
> > hard to maintain in the future.
>
> OK.
>
> > I'm not sure I understand the architecture of the whole app fully, so
> > please correct me if the following is erroneous.
> >
> > The application seems to sit somewhere between a "classical" web
> > applicaiton, with content generated by the server and a "rich
> > application", with "one page" containing the whole application and its
> > states managed by Javascript.  I think this leads to a poor separation of
> > concerns between the client and the server, and the boundary between the
> > two should be more clearly expressed.
> >
> > In my opinion, porting a desktop app to the browser should lend itself
> > naturally to a single page design, with the server merely acting as a
> > datastore returning json documents and static files. As such, frameworks
> > intended for this kind of application should be considered. I'm thinking
> > about two different approaches, but I'm not really familiar enough with
> > those>
> > technologies to recommend one or the other:
> >    - using  a "structural" framework, providing an MVC base, like
> >    Backbone,
> >
> > Ember or any of their counterparts. It should bring us  the structure of
> > the application, by allowing us to dice the javascript code into various
> > modules / submodules and helping us implement a proper separation of
> > concern between what is a view , a model etc...
> >
> >   - using a rich javascript application framework, like the  dojo toolkit
> >   or
> >
> > extjs. I used to be familiar with dojo toolkit, a bit less with ext, which
> > has licensing concerns anyway.
> >
> > There are probablly a ton more options, but think we should start asking
> > those questions to see where this takes us. I don't see the code base as
> > it is able to grow to the scope of the project.
>
> The main issue is that I'm new to this type of app development and am
> learning as I go - so I'm not surprised there are design issues. I've
> tried to ensure that I'm doing things in a sensible way by keeping in
> touch with people that are more experienced than I, but unfortunately
> they tend to be extremely busy. Any improvements you can suggest, or
> better yet, patch, are gratefully received. The primary design
> constraint is that we keep the code pluggable and highly extensible; I
> want to ensure it's easy for both the community and companies like
> ours in the community to be able to extend pgAdmin and use it as a
> framework for their own apps. I strongly believe it helps us all to
> work from a common base.

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


>
> Regarding the MVC base; that's exactly what Ashesh is working on at
> the moment - specifically he's looking at how we can use Backbone to
> provide the glue between the front and backend.

Great, Ashesh: I'm looking forward to hear from you as you progress towards
this goal. If you need any input, on this, feel free to contact me. Anyways,
I'll take a look at the proposed changes once they are published.

>
> Thank you for your input on this - I look forward to more :-)

--
Ronan Dunklau
http://dalibo.com - http://dalibo.org