Thread: [Patch] PGAdmin 4 JSON Handling

Hello.

I'm trying to dive into the PGAdmin 4 codebase, and one low hanging fruit that
I saw was the handling of JSON data.

The first patch is really trivial, and allows PgAdmin4 to run on system with
case sensitive filesystems.

JSON data should be returned to the client using an application/json MIME-
TYPE. Flask already provides an easy way to generate JSON response, with its
jsonify function.

This patch does not change anything architecturally, it just ensure that the
get_nodes method of each hook returns JSONizable objects, instead of building
them manually.

Moreover, there was a function already in place to return JSON document
according to a certain layout (everything under "data", with metadata attached
along the way), which was not used by the ACi tree. This patch also changes
this format to ensure the json responses returned by the application are
consistent.


On a side note, I have a few questions about the architecture of the
application.

- the "hooks" function should really implement a common class, instead of
relying on testing the presence of attributes to find a function. Essentially,
hooks modules are classes in disguise right now. I think it may be cleaner to
define our own Blueprint subclass to add those methods.
- regarding the jsonification, I feel like the NODE_TYPE should be a part of
the model itself, via a class attribute. A common method should be implemented
for all nodes, such as to eliminate duplicated code like the one which can be
found in the servers/hooks et server_groups/hooks get_nodes implementation

What are your thought on this ?

Sorry for the noise in the patch, but my vim configuration automatically
removes extraneous white spaces. If you'd prefer a separate patch for that, I
can try to generate one.

As for the Javascript, did you consider using a rich application  framework ?
For such a massive application as PgAdmin, I feel like developing each
component from a jquery plugin and some glue might not scale well with the
size of the app, and could lead to unmaintainable code.  By Rich Application
Framework, I'm thinking about something like Dojo or ExtJS.

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

Le jeudi 16 avril 2015 15:46:51 Ashesh Vashi a écrit :
> Hi Ronan,
>
> On Thu, Apr 16, 2015 at 2:49 PM, Ronan Dunklau <ronan.dunklau@dalibo.com>
>
> wrote:
> > Hello.
> >
> > I'm trying to dive into the PGAdmin 4 codebase, and one low hanging fruit
> > that
> > I saw was the handling of JSON data.
> >
> > The first patch is really trivial, and allows PgAdmin4 to run on system
> > with
> > case sensitive filesystems.
> >
> > JSON data should be returned to the client using an application/json MIME-
> > TYPE. Flask already provides an easy way to generate JSON response, with
> > its
> > jsonify function.
> >
> > This patch does not change anything architecturally, it just ensure that
> > the
> > get_nodes method of each hook returns JSONizable objects, instead of
> > building
> > them manually.
> >
> > Moreover, there was a function already in place to return JSON document
> > according to a certain layout (everything under "data", with metadata
> > attached
> > along the way), which was not used by the ACi tree. This patch also
> > changes
> > this format to ensure the json responses returned by the application are
> > consistent.
>
> Thanks for the patches.
> These changes are already been done in my current development work, which
> is still a WIP. (Hence - it has not been checked-in/shared.)
>
> Thanks any way.

Is there a public branch where I can see this WIP ?
As for the other proposals regarding the structure of the javascript code and
the module / hooks API, do you have any comment ?

Thank you.

>
> --
>
> 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>
>
> > On a side note, I have a few questions about the architecture of the
> > application.
> >
> > - the "hooks" function should really implement a common class, instead of
> > relying on testing the presence of attributes to find a function.
> > Essentially,
> > hooks modules are classes in disguise right now. I think it may be cleaner
> > to
> > define our own Blueprint subclass to add those methods.
> > - regarding the jsonification, I feel like the NODE_TYPE should be a part
> > of
> > the model itself, via a class attribute. A common method should be
> > implemented
> > for all nodes, such as to eliminate duplicated code like the one which can
> > be
> > found in the servers/hooks et server_groups/hooks get_nodes implementation
> >
> > What are your thought on this ?
> >
> > Sorry for the noise in the patch, but my vim configuration automatically
> > removes extraneous white spaces. If you'd prefer a separate patch for
> > that, I
> > can try to generate one.
> >
> > As for the Javascript, did you consider using a rich application
> > framework ?
> > For such a massive application as PgAdmin, I feel like developing each
> > component from a jquery plugin and some glue might not scale well with the
> > size of the app, and could lead to unmaintainable code.  By Rich
> > Application
> > Framework, I'm thinking about something like Dojo or ExtJS.
> >
> > --
> > Ronan Dunklau
> > http://dalibo.com - http://dalibo.org

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

On Thu, Apr 16, 2015 at 11:19 AM, Ronan Dunklau
<ronan.dunklau@dalibo.com> wrote:
> Le jeudi 16 avril 2015 15:46:51 Ashesh Vashi a écrit :
>> Hi Ronan,
>>
>> On Thu, Apr 16, 2015 at 2:49 PM, Ronan Dunklau <ronan.dunklau@dalibo.com>
>>
>> wrote:
>> > Hello.
>> >
>> > I'm trying to dive into the PGAdmin 4 codebase, and one low hanging fruit
>> > that
>> > I saw was the handling of JSON data.
>> >
>> > The first patch is really trivial, and allows PgAdmin4 to run on system
>> > with
>> > case sensitive filesystems.
>> >
>> > JSON data should be returned to the client using an application/json MIME-
>> > TYPE. Flask already provides an easy way to generate JSON response, with
>> > its
>> > jsonify function.
>> >
>> > This patch does not change anything architecturally, it just ensure that
>> > the
>> > get_nodes method of each hook returns JSONizable objects, instead of
>> > building
>> > them manually.
>> >
>> > Moreover, there was a function already in place to return JSON document
>> > according to a certain layout (everything under "data", with metadata
>> > attached
>> > along the way), which was not used by the ACi tree. This patch also
>> > changes
>> > this format to ensure the json responses returned by the application are
>> > consistent.
>>
>> Thanks for the patches.
>> These changes are already been done in my current development work, which
>> is still a WIP. (Hence - it has not been checked-in/shared.)
>>
>> Thanks any way.

Oh, they are?

> Is there a public branch where I can see this WIP ?

I assume it's all on his laptop. We (the pgAdmin project) have never
published WIP branches that I can recall, except for GSoC projects.

> As for the other proposals regarding the structure of the javascript code and
> the module / hooks API, do you have any comment ?

It's been on my personal TODO for a little while to sort out that code
into a proper OO class hierarchy as you suggest. Is that something you
would like to take a look at Ronan? I won't be touching it for quite a
while as I'm overloaded at the moment (which is why I asked Ashesh to
help out).

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

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

Le jeudi 16 avril 2015 11:40:14 Dave Page a écrit :
> On Thu, Apr 16, 2015 at 11:19 AM, Ronan Dunklau
>
> <ronan.dunklau@dalibo.com> wrote:
> > Le jeudi 16 avril 2015 15:46:51 Ashesh Vashi a écrit :
> >> Hi Ronan,
> >>
> >> On Thu, Apr 16, 2015 at 2:49 PM, Ronan Dunklau <ronan.dunklau@dalibo.com>
> >>
> >> wrote:
> >> > Hello.
> >> >
> >> > I'm trying to dive into the PGAdmin 4 codebase, and one low hanging
> >> > fruit
> >> > that
> >> > I saw was the handling of JSON data.
> >> >
> >> > The first patch is really trivial, and allows PgAdmin4 to run on system
> >> > with
> >> > case sensitive filesystems.
> >> >
> >> > JSON data should be returned to the client using an application/json
> >> > MIME-
> >> > TYPE. Flask already provides an easy way to generate JSON response,
> >> > with
> >> > its
> >> > jsonify function.
> >> >
> >> > This patch does not change anything architecturally, it just ensure
> >> > that
> >> > the
> >> > get_nodes method of each hook returns JSONizable objects, instead of
> >> > building
> >> > them manually.
> >> >
> >> > Moreover, there was a function already in place to return JSON document
> >> > according to a certain layout (everything under "data", with metadata
> >> > attached
> >> > along the way), which was not used by the ACi tree. This patch also
> >> > changes
> >> > this format to ensure the json responses returned by the application
> >> > are
> >> > consistent.
> >>
> >> Thanks for the patches.
> >> These changes are already been done in my current development work, which
> >> is still a WIP. (Hence - it has not been checked-in/shared.)
> >>
> >> Thanks any way.
>
> Oh, they are?
>
> > Is there a public branch where I can see this WIP ?
>
> I assume it's all on his laptop. We (the pgAdmin project) have never
> published WIP branches that I can recall, except for GSoC projects.
>
> > As for the other proposals regarding the structure of the javascript code
> > and the module / hooks API, do you have any comment ?
>
> It's been on my personal TODO for a little while to sort out that code
> into a proper OO class hierarchy as you suggest. Is that something you
> would like to take a look at Ronan? I won't be touching it for quite a
> while as I'm overloaded at the moment (which is why I asked Ashesh to
> help out).

Ok, I'm in the process of doing just that, I'll post a patch as soon as I have
something.



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

On Thu, Apr 16, 2015 at 2:44 PM, Ronan Dunklau <ronan.dunklau@dalibo.com> wrote:
> Le jeudi 16 avril 2015 11:40:14 Dave Page a écrit :
>> On Thu, Apr 16, 2015 at 11:19 AM, Ronan Dunklau
>>
>> <ronan.dunklau@dalibo.com> wrote:
>> > Le jeudi 16 avril 2015 15:46:51 Ashesh Vashi a écrit :
>> >> Hi Ronan,
>> >>
>> >> On Thu, Apr 16, 2015 at 2:49 PM, Ronan Dunklau <ronan.dunklau@dalibo.com>
>> >>
>> >> wrote:
>> >> > Hello.
>> >> >
>> >> > I'm trying to dive into the PGAdmin 4 codebase, and one low hanging
>> >> > fruit
>> >> > that
>> >> > I saw was the handling of JSON data.
>> >> >
>> >> > The first patch is really trivial, and allows PgAdmin4 to run on system
>> >> > with
>> >> > case sensitive filesystems.
>> >> >
>> >> > JSON data should be returned to the client using an application/json
>> >> > MIME-
>> >> > TYPE. Flask already provides an easy way to generate JSON response,
>> >> > with
>> >> > its
>> >> > jsonify function.
>> >> >
>> >> > This patch does not change anything architecturally, it just ensure
>> >> > that
>> >> > the
>> >> > get_nodes method of each hook returns JSONizable objects, instead of
>> >> > building
>> >> > them manually.
>> >> >
>> >> > Moreover, there was a function already in place to return JSON document
>> >> > according to a certain layout (everything under "data", with metadata
>> >> > attached
>> >> > along the way), which was not used by the ACi tree. This patch also
>> >> > changes
>> >> > this format to ensure the json responses returned by the application
>> >> > are
>> >> > consistent.
>> >>
>> >> Thanks for the patches.
>> >> These changes are already been done in my current development work, which
>> >> is still a WIP. (Hence - it has not been checked-in/shared.)
>> >>
>> >> Thanks any way.
>>
>> Oh, they are?
>>
>> > Is there a public branch where I can see this WIP ?
>>
>> I assume it's all on his laptop. We (the pgAdmin project) have never
>> published WIP branches that I can recall, except for GSoC projects.
>>
>> > As for the other proposals regarding the structure of the javascript code
>> > and the module / hooks API, do you have any comment ?
>>
>> It's been on my personal TODO for a little while to sort out that code
>> into a proper OO class hierarchy as you suggest. Is that something you
>> would like to take a look at Ronan? I won't be touching it for quite a
>> while as I'm overloaded at the moment (which is why I asked Ashesh to
>> help out).
>
> Ok, I'm in the process of doing just that, I'll post a patch as soon as I have
> something.

Cool, thanks.

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

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

Le jeudi 16 avril 2015 15:32:18 Dave Page a écrit :
> On Thu, Apr 16, 2015 at 2:44 PM, Ronan Dunklau <ronan.dunklau@dalibo.com>
wrote:
> > Le jeudi 16 avril 2015 11:40:14 Dave Page a écrit :
> >> On Thu, Apr 16, 2015 at 11:19 AM, Ronan Dunklau
> >>
> >> <ronan.dunklau@dalibo.com> wrote:
> >> > Le jeudi 16 avril 2015 15:46:51 Ashesh Vashi a écrit :
> >> >> Hi Ronan,
> >> >>
> >> >> On Thu, Apr 16, 2015 at 2:49 PM, Ronan Dunklau
> >> >> <ronan.dunklau@dalibo.com>
> >> >>
> >> >> wrote:
> >> >> > Hello.
> >> >> >
> >> >> > I'm trying to dive into the PGAdmin 4 codebase, and one low hanging
> >> >> > fruit
> >> >> > that
> >> >> > I saw was the handling of JSON data.
> >> >> >
> >> >> > The first patch is really trivial, and allows PgAdmin4 to run on
> >> >> > system
> >> >> > with
> >> >> > case sensitive filesystems.
> >> >> >
> >> >> > JSON data should be returned to the client using an application/json
> >> >> > MIME-
> >> >> > TYPE. Flask already provides an easy way to generate JSON response,
> >> >> > with
> >> >> > its
> >> >> > jsonify function.
> >> >> >
> >> >> > This patch does not change anything architecturally, it just ensure
> >> >> > that
> >> >> > the
> >> >> > get_nodes method of each hook returns JSONizable objects, instead of
> >> >> > building
> >> >> > them manually.
> >> >> >
> >> >> > Moreover, there was a function already in place to return JSON
> >> >> > document
> >> >> > according to a certain layout (everything under "data", with
> >> >> > metadata
> >> >> > attached
> >> >> > along the way), which was not used by the ACi tree. This patch also
> >> >> > changes
> >> >> > this format to ensure the json responses returned by the application
> >> >> > are
> >> >> > consistent.
> >> >>
> >> >> Thanks for the patches.
> >> >> These changes are already been done in my current development work,
> >> >> which
> >> >> is still a WIP. (Hence - it has not been checked-in/shared.)
> >> >>
> >> >> Thanks any way.
> >>
> >> Oh, they are?
> >>
> >> > Is there a public branch where I can see this WIP ?
> >>
> >> I assume it's all on his laptop. We (the pgAdmin project) have never
> >> published WIP branches that I can recall, except for GSoC projects.
> >>
> >> > As for the other proposals regarding the structure of the javascript
> >> > code
> >> > and the module / hooks API, do you have any comment ?
> >>
> >> It's been on my personal TODO for a little while to sort out that code
> >> into a proper OO class hierarchy as you suggest. Is that something you
> >> would like to take a look at Ronan? I won't be touching it for quite a
> >> while as I'm overloaded at the moment (which is why I asked Ashesh to
> >> help out).
> >
> > Ok, I'm in the process of doing just that, I'll post a patch as soon as I
> > have something.
>
> Cool, thanks.

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.

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


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.


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

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

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

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.

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

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

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

On Mon, Apr 20, 2015 at 5:40 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Apr 20, 2015 at 10:52 AM, Ronan Dunklau
> > 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 this.  A lot of the unified frameworks have problems that should
make you very cautious in terms of using them for the general case.
Beware libraries that are 'all in' and make it difficult to mix/match
different widgets.

Even some of the best frameworks, such as angular, can be difficult to
write highly performant code against because there is so much action
at a distance going on.  For my 0.02$ I'll throw slickgrid into the
mix which is a very fast library (see:
http://mleibman.github.io/SlickGrid/examples/example-optimizing-dataview.html)
and a good API.  For a general purpose admin tool, performance is very
important.

merlin

On Mon, Apr 20, 2015 at 3:36 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Mon, Apr 20, 2015 at 5:40 AM, Dave Page <dpage@pgadmin.org> wrote:
>> On Mon, Apr 20, 2015 at 10:52 AM, Ronan Dunklau
>> > 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 this.  A lot of the unified frameworks have problems that should
> make you very cautious in terms of using them for the general case.
> Beware libraries that are 'all in' and make it difficult to mix/match
> different widgets.
>
> Even some of the best frameworks, such as angular, can be difficult to
> write highly performant code against because there is so much action
> at a distance going on.  For my 0.02$ I'll throw slickgrid into the
> mix which is a very fast library (see:
> http://mleibman.github.io/SlickGrid/examples/example-optimizing-dataview.html)
> and a good API.  For a general purpose admin tool, performance is very
> important.

Ooh, that's nice. I have a feeling we're going to need a grid control soon :-)


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

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

Le jeudi 23 avril 2015 10:53:48 Ashesh Vashi a écrit :

> Hi Dave/Ronan,

>

> On Mon, Apr 20, 2015 at 4:10 PM, Dave Page <dpage@pgadmin.org> wrote:

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

>

> Thanks - It looks good to me.

> (And, attached patch is based on that.)

Maybe I'm missing something, but it seems like a "generate_browser_node" function is missing:

File "/home/ro/projets/pgadmin4/web/pgadmin/browser/server_groups/__init__.py", line 21, in <module>

from pgadmin.browser.utils import generate_browser_node

ImportError: cannot import name generate_browser_node

It also brought to my attention that I should have removed the only function (register_modules) from pgadmin.browser.utils.

Thank you for integrating my work into your patch !

--

Ronan Dunklau

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

On Thu, Apr 23, 2015 at 8:22 AM, Ronan Dunklau <ronan.dunklau@dalibo.com> wrote:
> Le jeudi 23 avril 2015 10:53:48 Ashesh Vashi a écrit :
>
>> Hi Dave/Ronan,
>
>>
>
>> On Mon, Apr 20, 2015 at 4:10 PM, Dave Page <dpage@pgadmin.org> wrote:
>
>> > 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.
>
>>
>
>> Thanks - It looks good to me.
>
>> (And, attached patch is based on that.)
>
>
>
>
>
> Maybe I'm missing something, but it seems like a "generate_browser_node"
> function is missing:
>
>
>
> File
> "/home/ro/projets/pgadmin4/web/pgadmin/browser/server_groups/__init__.py",
> line 21, in <module>
>
> from pgadmin.browser.utils import generate_browser_node
>
> ImportError: cannot import name generate_browser_node
>
>
>
>
>
> It also brought to my attention that I should have removed the only function
> (register_modules) from pgadmin.browser.utils.

I'll take a look once these issues are resolved...


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

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

Le jeudi 23 avril 2015 11:44:49 Dave Page a écrit :
> On Thu, Apr 23, 2015 at 9:18 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com
> > wrote:
> >
> >
> > On Thu, Apr 23, 2015 at 12:52 PM, Ronan Dunklau <ronan.dunklau@dalibo.com>
> >
> > wrote:
> >>  Le jeudi 23 avril 2015 10:53:48 Ashesh Vashi a écrit :
> >> > Hi Dave/Ronan,
> >> >
> >> > On Mon, Apr 20, 2015 at 4:10 PM, Dave Page <dpage@pgadmin.org> wrote:
> >> > > 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.
> >> >
> >> > Thanks - It looks good to me.
> >> >
> >> > (And, attached patch is based on that.)
> >>
> >> Maybe I'm missing something, but it seems like a "generate_browser_node"
> >> function is missing:
> >>
> >>
> >>
> >> File
> >> "/home/ro/projets/pgadmin4/web/pgadmin/browser/server_groups/__init__.py"
> >> ,
> >> line 21, in <module>
> >>
> >> from pgadmin.browser.utils import generate_browser_node
> >>
> >> ImportError: cannot import name generate_browser_node
> >>
> >>
> >>
> >>
> >>
> >> It also brought to my attention that I should have removed the only
> >> function (register_modules) from pgadmin.browser.utils.
> >
> > Yeah - it is missing.
> > Please find a separate patch for the utils.
> >
> > Actually - you removed the web/pgadmin/browser/utils.py, hence - when I
> > made the patch on top of yours, git detected the file as new file, and did
> > not include the diff for it.
> > The attached patch is only for utils file.
>
> Hi
>
> I can't persuade these patches to apply to my tree. When you get a minute,
> can you please send me a complete 'git diff' of everything from HEAD?
>
> Thanks.

Here is the diff from my tree after applying both Ashesh's patches on top of
mine.

As for the json handling, what do you think about using standard http codes ?
It feels a bit strange to receive a 200 when the operation could not be
completed.

For example, right now, adding a server returns a "missing required parameter
(host)." That should return a 400 (Bad Request) in my opinion, with the
detailed error message in the response.


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

On Thu, Apr 23, 2015 at 12:42 PM, Ronan Dunklau
<ronan.dunklau@dalibo.com> wrote:
> Le jeudi 23 avril 2015 11:44:49 Dave Page a écrit :
>> On Thu, Apr 23, 2015 at 9:18 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com
>> > wrote:
>> >
>> >
>> > On Thu, Apr 23, 2015 at 12:52 PM, Ronan Dunklau <ronan.dunklau@dalibo.com>
>> >
>> > wrote:
>> >>  Le jeudi 23 avril 2015 10:53:48 Ashesh Vashi a écrit :
>> >> > Hi Dave/Ronan,
>> >> >
>> >> > On Mon, Apr 20, 2015 at 4:10 PM, Dave Page <dpage@pgadmin.org> wrote:
>> >> > > 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.
>> >> >
>> >> > Thanks - It looks good to me.
>> >> >
>> >> > (And, attached patch is based on that.)
>> >>
>> >> Maybe I'm missing something, but it seems like a "generate_browser_node"
>> >> function is missing:
>> >>
>> >>
>> >>
>> >> File
>> >> "/home/ro/projets/pgadmin4/web/pgadmin/browser/server_groups/__init__.py"
>> >> ,
>> >> line 21, in <module>
>> >>
>> >> from pgadmin.browser.utils import generate_browser_node
>> >>
>> >> ImportError: cannot import name generate_browser_node
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> It also brought to my attention that I should have removed the only
>> >> function (register_modules) from pgadmin.browser.utils.
>> >
>> > Yeah - it is missing.
>> > Please find a separate patch for the utils.
>> >
>> > Actually - you removed the web/pgadmin/browser/utils.py, hence - when I
>> > made the patch on top of yours, git detected the file as new file, and did
>> > not include the diff for it.
>> > The attached patch is only for utils file.
>>
>> Hi
>>
>> I can't persuade these patches to apply to my tree. When you get a minute,
>> can you please send me a complete 'git diff' of everything from HEAD?
>>
>> Thanks.
>
> Here is the diff from my tree after applying both Ashesh's patches on top of
> mine.

Thanks, but I think I'm still missing something. This is your patch
applied to the current HEAD (BTW, please use "git diff" to create
patches - the apply a lot more reliably than whatever you're currently
doing, which "git apply" just doesn't like):

(pgadmin4)piranha:web dpage$ python pgAdmin4.py
2015-04-28 09:57:14,966: INFO pgadmin:
################################################################################
2015-04-28 09:57:14,966: INFO pgadmin: Starting pgAdmin 4 v1.0.0-dev...
2015-04-28 09:57:14,966: INFO pgadmin:
################################################################################
2015-04-28 09:57:14,966: DEBUG pgadmin: Python syspath:
['/Users/dpage/git/pgadmin4/web',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/pip-6.0.8-py2.7.egg',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/pytz-2014.10-py2.7.egg',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python27.zip',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/plat-darwin',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/plat-mac',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/plat-mac/lib-scriptpackages',
'/Users/dpage/.virtualenvs/pgadmin4/Extras/lib/python',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/lib-tk',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/lib-old',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/lib-dynload',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
'/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages']
2015-04-28 09:57:14,967: DEBUG pgadmin: Available translations: [Locale('fr')]
2015-04-28 09:57:14,976: INFO pgadmin: Examining potential module: pgadmin.about
2015-04-28 09:57:14,977: INFO pgadmin: Registering blueprint module:
<pgadmin.about.AboutModule object at 0x10b1e5410>
2015-04-28 09:57:14,977: INFO pgadmin: Examining potential module:
pgadmin.about.hooks
2015-04-28 09:57:14,977: INFO pgadmin: Examining potential module:
pgadmin.about.views
2015-04-28 09:57:14,978: INFO pgadmin: Examining potential module:
pgadmin.browser
2015-04-28 09:57:14,979: INFO pgadmin: Registering blueprint module:
<pgadmin.browser.BrowserModule object at 0x10b23e5d0>
2015-04-28 09:57:14,979: INFO pgadmin: Examining potential module:
pgadmin.browser.hooks
Traceback (most recent call last):
  File "pgAdmin4.py", line 51, in <module>
    app = create_app()
  File "/Users/dpage/git/pgadmin4/web/pgadmin/__init__.py", line 160,
in create_app
    app.register_blueprint(module)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 62, in wrapper_func
    return f(self, *args, **kwargs)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 889, in register_blueprint
    blueprint.register(self, options, first_registration)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/__init__.py", line
29, in register
    self.submodules = list(app.find_submodules(self.import_name))
  File "/Users/dpage/git/pgadmin4/web/pgadmin/__init__.py", line 40,
in find_submodules
    module = import_module(module_name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
line 37, in import_module
    __import__(name)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/hooks.py", line
15, in <module>
ImportError: cannot import name register_modules

> As for the json handling, what do you think about using standard http codes ?
> It feels a bit strange to receive a 200 when the operation could not be
> completed.
>
> For example, right now, adding a server returns a "missing required parameter
> (host)." That should return a 400 (Bad Request) in my opinion, with the
> detailed error message in the response.

Agreed. Patches welcome as always :-)

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

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

Le mardi 28 avril 2015 10:00:08 Dave Page a écrit :
> On Thu, Apr 23, 2015 at 12:42 PM, Ronan Dunklau
>
> <ronan.dunklau@dalibo.com> wrote:
> > Le jeudi 23 avril 2015 11:44:49 Dave Page a écrit :
> >> On Thu, Apr 23, 2015 at 9:18 AM, Ashesh Vashi
> >> <ashesh.vashi@enterprisedb.com>>
> >> > wrote:
> >> >
> >> >
> >> > On Thu, Apr 23, 2015 at 12:52 PM, Ronan Dunklau
> >> > <ronan.dunklau@dalibo.com>
> >> >
> >> > wrote:
> >> >>  Le jeudi 23 avril 2015 10:53:48 Ashesh Vashi a écrit :
> >> >> > Hi Dave/Ronan,
> >> >> >
> >> >> > On Mon, Apr 20, 2015 at 4:10 PM, Dave Page <dpage@pgadmin.org>
wrote:
> >> >> > > 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.
> >> >> >
> >> >> > Thanks - It looks good to me.
> >> >> >
> >> >> > (And, attached patch is based on that.)
> >> >>
> >> >> Maybe I'm missing something, but it seems like a
> >> >> "generate_browser_node"
> >> >> function is missing:
> >> >>
> >> >>
> >> >>
> >> >> File
> >> >> "/home/ro/projets/pgadmin4/web/pgadmin/browser/server_groups/__init__.
> >> >> py"
> >> >> ,
> >> >> line 21, in <module>
> >> >>
> >> >> from pgadmin.browser.utils import generate_browser_node
> >> >>
> >> >> ImportError: cannot import name generate_browser_node
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> It also brought to my attention that I should have removed the only
> >> >> function (register_modules) from pgadmin.browser.utils.
> >> >
> >> > Yeah - it is missing.
> >> > Please find a separate patch for the utils.
> >> >
> >> > Actually - you removed the web/pgadmin/browser/utils.py, hence - when I
> >> > made the patch on top of yours, git detected the file as new file, and
> >> > did
> >> > not include the diff for it.
> >> > The attached patch is only for utils file.
> >>
> >> Hi
> >>
> >> I can't persuade these patches to apply to my tree. When you get a
> >> minute,
> >> can you please send me a complete 'git diff' of everything from HEAD?
> >>
> >> Thanks.
> >
> > Here is the diff from my tree after applying both Ashesh's patches on top
> > of mine.
>
> Thanks, but I think I'm still missing something. This is your patch
> applied to the current HEAD (BTW, please use "git diff" to create
> patches - the apply a lot more reliably than whatever you're currently
> doing, which "git apply" just doesn't like):

I'm using git diff -u, so patch -p1 should apply it just fine. I'll use plain
git diff next time if git apply is what you use.

>
> (pgadmin4)piranha:web dpage$ python pgAdmin4.py
> 2015-04-28 09:57:14,966: INFO pgadmin:
> ############################################################################
> #### 2015-04-28 09:57:14,966: INFO pgadmin: Starting pgAdmin 4 v1.0.0-dev...
> 2015-04-28 09:57:14,966: INFO pgadmin:
> ############################################################################
> #### 2015-04-28 09:57:14,966: DEBUG pgadmin: Python syspath:
> ['/Users/dpage/git/pgadmin4/web',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/setuptools-0
> .6c11-py2.7.egg',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/pip-6.0.8-p
> y2.7.egg',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/pytz-2014.1
> 0-py2.7.egg', '/Users/dpage/.virtualenvs/pgadmin4/lib/python27.zip',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/plat-darwin',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/plat-mac',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/plat-mac/lib-scriptpackage
> s', '/Users/dpage/.virtualenvs/pgadmin4/Extras/lib/python',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/lib-tk',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/lib-old',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/lib-dynload',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat
> -darwin',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib
> -tk',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pla
> t-mac',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pla
> t-mac/lib-scriptpackages',
> '/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages']
> 2015-04-28 09:57:14,967: DEBUG pgadmin: Available translations:
> [Locale('fr')] 2015-04-28 09:57:14,976: INFO pgadmin: Examining potential
> module: pgadmin.about 2015-04-28 09:57:14,977: INFO pgadmin: Registering
> blueprint module: <pgadmin.about.AboutModule object at 0x10b1e5410>
> 2015-04-28 09:57:14,977: INFO pgadmin: Examining potential module:
> pgadmin.about.hooks
> 2015-04-28 09:57:14,977: INFO pgadmin: Examining potential module:
> pgadmin.about.views
> 2015-04-28 09:57:14,978: INFO pgadmin: Examining potential module:
> pgadmin.browser
> 2015-04-28 09:57:14,979: INFO pgadmin: Registering blueprint module:
> <pgadmin.browser.BrowserModule object at 0x10b23e5d0>
> 2015-04-28 09:57:14,979: INFO pgadmin: Examining potential module:
> pgadmin.browser.hooks
> Traceback (most recent call last):
>   File "pgAdmin4.py", line 51, in <module>
>     app = create_app()
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/__init__.py", line 160,
> in create_app
>     app.register_blueprint(module)
>   File
> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p
> y", line 62, in wrapper_func
>     return f(self, *args, **kwargs)
>   File
> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p
> y", line 889, in register_blueprint
>     blueprint.register(self, options, first_registration)
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/__init__.py", line
> 29, in register
>     self.submodules = list(app.find_submodules(self.import_name))
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/__init__.py", line 40,
> in find_submodules
>     module = import_module(module_name)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imp
> ortlib/__init__.py", line 37, in import_module
>     __import__(name)
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/hooks.py", line
> 15, in <module>
> ImportError: cannot import name register_modules

I think the problem here might be that you have stale bytecompiled files, in
particular pgadmin/browser/hooks, which should not exist anymore.

find -name "*.pyc" -delete

When developing, it can be useful to set the env variable
PYTHONDONTWRITEBYTECODE to prevent the interpreter from generating those
files.


>
> > As for the json handling, what do you think about using standard http
> > codes ? It feels a bit strange to receive a 200 when the operation could
> > not be completed.
> >
> > For example, right now, adding a server returns a "missing required
> > parameter (host)." That should return a 400 (Bad Request) in my opinion,
> > with the detailed error message in the response.
>
> Agreed. Patches welcome as always :-)

I'll wait until these patches and Ashesh work on Backbone to get merged before
submitting anything else. The changes are already invasive.

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

On Tue, Apr 28, 2015 at 10:28 AM, Ronan Dunklau
<ronan.dunklau@dalibo.com> wrote:
>
>> Thanks, but I think I'm still missing something. This is your patch
>> applied to the current HEAD (BTW, please use "git diff" to create
>> patches - the apply a lot more reliably than whatever you're currently
>> doing, which "git apply" just doesn't like):
>
> I'm using git diff -u, so patch -p1 should apply it just fine. I'll use plain
> git diff next time if git apply is what you use.

Thanks!

>> ImportError: cannot import name register_modules
>
> I think the problem here might be that you have stale bytecompiled files, in
> particular pgadmin/browser/hooks, which should not exist anymore.
>
> find -name "*.pyc" -delete

Ah, yes - that was it.

> When developing, it can be useful to set the env variable
> PYTHONDONTWRITEBYTECODE to prevent the interpreter from generating those
> files.

Cool, thanks for the tip.

>> > As for the json handling, what do you think about using standard http
>> > codes ? It feels a bit strange to receive a 200 when the operation could
>> > not be completed.
>> >
>> > For example, right now, adding a server returns a "missing required
>> > parameter (host)." That should return a 400 (Bad Request) in my opinion,
>> > with the detailed error message in the response.
>>
>> Agreed. Patches welcome as always :-)
>
> I'll wait until these patches and Ashesh work on Backbone to get merged before
> submitting anything else. The changes are already invasive.

OK. Unfortunately they also seem to have broken a number of things:

- Server icons are no longer displayed on the treeview

- Renaming a server fails with:

2015-04-28 11:25:54,855: INFO werkzeug: 127.0.0.1 - - [28/Apr/2015
11:25:54] "PUT /browser/server/obj/1 HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1453, in dispatch_request
    self.raise_routing_exception(req)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1439, in raise_routing_exception
    raise FormDataRoutingRedirect(request)
FormDataRoutingRedirect: A request was sent to this URL
(http://127.0.0.1:5050/browser/server/obj/1) but a redirect was issued
automatically by the routing system to
"http://127.0.0.1:5050/browser/server/obj/1/".  The URL was defined
with a trailing slash so Flask will automatically redirect to the URL
with the trailing slash if it was accessed without one.  Make sure to
directly send your PUT-request to this URL since we can't make
browsers or HTTP clients redirect with form data reliably or without
user interaction.

- Right-clicking on the tab bar and selecting any of the options to
open new panels (Online Help, pgAdmin Website etc.) no longer works.

- When creating a new server group, they are added to the treeview
with the name "undefined". Refreshing the page corrects the issue.

- Deleting or renaming a server group is reflected on the treeview,
but not saved to the database so the change is reverted on refresh.

- Generate Test HTML fails with:

2015-04-28 11:30:15,135: INFO werkzeug: 127.0.0.1 - - [28/Apr/2015
11:30:15] "GET /test/generated HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask_login.py",
line 758, in decorated_view
    return func(*args, **kwargs)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/test/__init__.py", line
69, in generated
    <a href="http://www.pgadmin.org/">%s v%s</a>""" % (ctime(time()),
config.APP_NAME, config.APP_VERSION)
NameError: global name 'config' is not defined
2015-04-28 11:30:15,149: INFO werkzeug: 127.0.0.1 - - [28/Apr/2015
11:30:15] "POST /settings/store HTTP/1.1" 200 -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 63524)
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py",
line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py",
line 321, in process_request
    self.finish_request(request, client_address)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py",
line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py",
line 651, in __init__
    self.finish()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py",
line 710, in finish
    self.wfile.close()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py",
line 279, in close
    self.flush()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py",
line 303, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe
----------------------------------------

Are you aware of these issues Ashesh?

Thanks.

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

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

Le mardi 28 avril 2015 11:32:05 Dave Page a écrit :

> On Tue, Apr 28, 2015 at 10:28 AM, Ronan Dunklau

>

> <ronan.dunklau@dalibo.com> wrote:

> >> Thanks, but I think I'm still missing something. This is your patch

> >> applied to the current HEAD (BTW, please use "git diff" to create

> >> patches - the apply a lot more reliably than whatever you're currently

> >

> >> doing, which "git apply" just doesn't like):

> > I'm using git diff -u, so patch -p1 should apply it just fine. I'll use

> > plain git diff next time if git apply is what you use.

>

> Thanks!

>

> >> ImportError: cannot import name register_modules

> >

> > I think the problem here might be that you have stale bytecompiled files,

> > in particular pgadmin/browser/hooks, which should not exist anymore.

> >

> > find -name "*.pyc" -delete

>

> Ah, yes - that was it.

>

> > When developing, it can be useful to set the env variable

> > PYTHONDONTWRITEBYTECODE to prevent the interpreter from generating those

> > files.

>

> Cool, thanks for the tip.

>

> >> > As for the json handling, what do you think about using standard http

> >> > codes ? It feels a bit strange to receive a 200 when the operation

> >> > could

> >> > not be completed.

> >> >

> >> > For example, right now, adding a server returns a "missing required

> >> > parameter (host)." That should return a 400 (Bad Request) in my

> >> > opinion,

> >> > with the detailed error message in the response.

> >>

> >> Agreed. Patches welcome as always :-)

> >

> > I'll wait until these patches and Ashesh work on Backbone to get merged

> > before submitting anything else. The changes are already invasive.

>

> OK. Unfortunately they also seem to have broken a number of things:

>

> - Server icons are no longer displayed on the treeview

>

Fixed

> - Renaming a server fails with:

>

> 2015-04-28 11:25:54,855: INFO werkzeug: 127.0.0.1 - - [28/Apr/2015

> 11:25:54] "PUT /browser/server/obj/1 HTTP/1.1" 500 -

> Traceback (most recent call last):

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1836, in __call__

> return self.wsgi_app(environ, start_response)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1820, in wsgi_app

> response = self.make_response(self.handle_exception(e))

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1403, in handle_exception

> reraise(exc_type, exc_value, tb)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1817, in wsgi_app

> response = self.full_dispatch_request()

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1477, in full_dispatch_request

> rv = self.handle_user_exception(e)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1381, in handle_user_exception

> reraise(exc_type, exc_value, tb)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1475, in full_dispatch_request

> rv = self.dispatch_request()

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1453, in dispatch_request

> self.raise_routing_exception(req)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1439, in raise_routing_exception

> raise FormDataRoutingRedirect(request)

> FormDataRoutingRedirect: A request was sent to this URL

> (http://127.0.0.1:5050/browser/server/obj/1) but a redirect was issued

> automatically by the routing system to

> "http://127.0.0.1:5050/browser/server/obj/1/". The URL was defined

> with a trailing slash so Flask will automatically redirect to the URL

> with the trailing slash if it was accessed without one. Make sure to

> directly send your PUT-request to this URL since we can't make

> browsers or HTTP clients redirect with form data reliably or without

> user interaction.

>

Did it ever work ? I was not able to test this feature before, because of missing imports, so I just assumed it was not working in the first place.

> - Right-clicking on the tab bar and selecting any of the options to

> open new panels (Online Help, pgAdmin Website etc.) no longer works.

Small typo from me, fixed in attached page.

>

> - When creating a new server group, they are added to the treeview

> with the name "undefined". Refreshing the page corrects the issue

> .

>

> - Deleting or renaming a server group is reflected on the treeview,

> but not saved to the database so the change is reverted on refresh.

I'll let Ashesh handle these one, probably introduced during his refactoring of CRUD operations.

>

> - Generate Test HTML fails with:

>

> 2015-04-28 11:30:15,135: INFO werkzeug: 127.0.0.1 - - [28/Apr/2015

> 11:30:15] "GET /test/generated HTTP/1.1" 500 -

> Traceback (most recent call last):

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1836, in __call__

> return self.wsgi_app(environ, start_response)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1820, in wsgi_app

> response = self.make_response(self.handle_exception(e))

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1403, in handle_exception

> reraise(exc_type, exc_value, tb)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1817, in wsgi_app

> response = self.full_dispatch_request()

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1477, in full_dispatch_request

> rv = self.handle_user_exception(e)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1381, in handle_user_exception

> reraise(exc_type, exc_value, tb)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1475, in full_dispatch_request

> rv = self.dispatch_request()

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p

> y", line 1461, in dispatch_request

> return self.view_functions[rule.endpoint](**req.view_args)

> File

> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask_login

> .py", line 758, in decorated_view

> return func(*args, **kwargs)

> File "/Users/dpage/git/pgadmin4/web/pgadmin/test/__init__.py", line

> 69, in generated

> <a href="http://www.pgadmin.org/">%s v%s</a>""" % (ctime(time()),

> config.APP_NAME, config.APP_VERSION)

> NameError: global name 'config' is not defined

> 2015-04-28 11:30:15,149: INFO werkzeug: 127.0.0.1 - - [28/Apr/2015

> 11:30:15] "POST /settings/store HTTP/1.1" 200 -

> ----------------------------------------

> Exception happened during processing of request from ('127.0.0.1', 63524)

> Traceback (most recent call last):

> File

> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Soc

> ketServer.py", line 295, in _handle_request_noblock

> self.process_request(request, client_address)

> File

> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Soc

> ketServer.py", line 321, in process_request

> self.finish_request(request, client_address)

> File

> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Soc

> ketServer.py", line 334, in finish_request

> self.RequestHandlerClass(request, client_address, self)

> File

> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Soc

> ketServer.py", line 651, in __init__

> self.finish()

> File

> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Soc

> ketServer.py", line 710, in finish

> self.wfile.close()

> File

> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/soc

> ket.py", line 279, in close

> self.flush()

> File

> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/soc

> ket.py", line 303, in flush

> self._sock.sendall(view[write_offset:write_offset+buffer_size])

> error: [Errno 32] Broken pipe

> ----------------------------------------

Fixed in the attached patch,; to apply from master.

>

> Are you aware of these issues Ashesh?

>

> Thanks.

--

Ronan Dunklau

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

On Tue, Apr 28, 2015 at 12:21 PM, Ronan Dunklau
<ronan.dunklau@dalibo.com> wrote:
>
>> - Server icons are no longer displayed on the treeview
>
> Fixed
>

Confirmed.

>> - Renaming a server fails with:
>
> Did it ever work ? I was not able to test this feature before, because of
> missing imports, so I just assumed it was not working in the first place.

It did at one point, but it does currently seem to be broken in HEAD.
Probably my fault. I'll leave it for now until this work is complete.

>> - Right-clicking on the tab bar and selecting any of the options to
>> open new panels (Online Help, pgAdmin Website etc.) no longer works.
>
> Small typo from me, fixed in attached page.

Confirmed.

>> - When creating a new server group, they are added to the treeview
>> with the name "undefined". Refreshing the page corrects the issue
>>
>> - Deleting or renaming a server group is reflected on the treeview,
>
>> but not saved to the database so the change is reverted on refresh.
>
> I'll let Ashesh handle these one, probably introduced during his refactoring
> of CRUD operations.

OK

>> - Generate Test HTML fails with:
>
> Fixed in the attached patch,; to apply from master.

Confirmed.

Thanks Ronan!

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

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

Le mardi 28 avril 2015 13:54:47 Dave Page a écrit :
> On Tue, Apr 28, 2015 at 12:21 PM, Ronan Dunklau
>
> <ronan.dunklau@dalibo.com> wrote:
> >> - Server icons are no longer displayed on the treeview
> >
> > Fixed
>
> Confirmed.
>
> >> - Renaming a server fails with:
> > Did it ever work ? I was not able to test this feature before, because of
> > missing imports, so I just assumed it was not working in the first place.
>
> It did at one point, but it does currently seem to be broken in HEAD.
> Probably my fault. I'll leave it for now until this work is complete.
>
> >> - Right-clicking on the tab bar and selecting any of the options to
> >> open new panels (Online Help, pgAdmin Website etc.) no longer works.
> >
> > Small typo from me, fixed in attached page.
>
> Confirmed.
>
> >> - When creating a new server group, they are added to the treeview
> >> with the name "undefined". Refreshing the page corrects the issue
> >>
> >> - Deleting or renaming a server group is reflected on the treeview,
> >>
> >> but not saved to the database so the change is reverted on refresh.
> >
> > I'll let Ashesh handle these one, probably introduced during his
> > refactoring of CRUD operations.
>
> OK
>
> >> - Generate Test HTML fails with:
> > Fixed in the attached patch,; to apply from master.
>
> Confirmed.
>
> Thanks Ronan!

Where are we regarding the integration of these changes ?

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