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

On Mon, Apr 20, 2015 at 2:02 PM, Ronan Dunklau <ronan.dunklau@dalibo.com> wrote:
>
> I don't know what your requirements are, but I understand that finding a set of
> components with the right functionality is hard. For me it all boils down to a
> (complex) comparison of the costs involved in:
>  - integrating heterogeneous component, in their data structures, event
> handling, look and feel
>  - extending existing homogeneous components to provide the feature set
> needed.

It's possible one or two other components could have been extended to
provide the required functionality, but;

- I found nothing even remotely close to usable for providing the
docking features of wcDocker we want.

- I found nothing close to CodeMirror for an editor. There were a
couple of other third party controls that could do the syntax
highlighting, but nothing that could also do block folding,
search/replace, indicators, auto-complete etc.

- We've tried a few tree controls in EDB on another project; none
seemed to work as well as aciTree, which again, has a much richer API
than other controls. We won't need all the functionality of course,
but it was clearly written as a multi-purpose control, unlike the
other options we've seen which seem much more limited, as if they've
been written originally with a specific use in mind. As you can
imagine, pgAdmin revolves around that control, and we do need
something flexible there.

I'm confident that using heterogenous controls that are best in their
class is the best option for us.

>> > +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.
>
> In addition to loading modules from the base applciction path, modules could
> be searched from an extensions namespace (for example, pgadmin.ext). That way,
> new extensions can be installed directly using standard python packaging
> tools, provided they are declared in the right package. This also allows to
> benefit from distros packaing chains, since (at least for rpm / deb) there is
> an easy way to build a package from a python package. It wouldn't change much
> from the existing directory structure, but would allow to piggy back on the
> python package system.

That certainly sounds interesting. How would you suggest tree nodes
figure out where to attach themselves? Load them all, then call a
function in each that allows them to register themselves with their
parents?

> As for the drawn out discussions, please excuse me for that, that was not my
> goal. As I am just getting my feet wet with this project, I have a lot of
> questions for which I am not finding an answer on the mailing list or the
> redmine wiki.

You misunderstand - I want to prevent the discussion from becoming
drawn out in the future. It's nowhere near that point yet :-)

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

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