Re: [Patch] PGAdmin 4 JSON Handling - Mailing list pgadmin-hackers

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?

> 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

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

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

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.

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

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company