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

Поиск
Список
Период
Сортировка
От Ronan Dunklau
Тема Re: PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling)
Дата
Msg-id 4901049.iDdtTTIuSZ@ronan.dunklau.fr
обсуждение исходный текст
Ответ на Re: PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling)  (Dave Page <dpage@pgadmin.org>)
Ответы Re: PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling)
Список pgadmin-hackers
Le lundi 20 avril 2015 11:40:48 Dave Page a écrit :
> 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.
>
> >> > 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.
>
> >> > 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.

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.


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

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.

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

Вложения

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling)
Следующее
От: Dave Page
Дата:
Сообщение: Re: PGAdmin 4 architecture (Was: [Patch] PGAdmin 4 JSON Handling)