Re: [pgAdmin4][PATCH] To fix the issue with Node rename

From: Joao Pedro De Almeida Pereira <jdealmeidapereira(at)pivotal(dot)io>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Murtuza Zabuawala <murtuza(dot)zabuawala(at)enterprisedb(dot)com>, Harshal Dhumal <harshal(dot)dhumal(at)enterprisedb(dot)com>, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: [pgAdmin4][PATCH] To fix the issue with Node rename
Date: 2017-05-18 14:52:46
Message-ID: CAE+jjam6k_pygmv74o=dubiePTCHmAJi3462VbfofTnTA=P2pA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hello Hackers,

@Dave, @Murtuza
We do understand that the changes are tightly coupled with the tree, but if
we want to be able to upgrade our tree menu in the future, we need to start
decoupling functionality and the underlaying tree.
Another step that we can take is to change our variable naming convention
because variables like _d or this.i do not communicate their purpose,
making it hard to read.

Thanks
Joao & Shruti

On Wed, May 17, 2017 at 11:05 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Wed, May 17, 2017 at 11:41 AM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> Hi Joao,
>>
>> Yes, this patch is related to browser tree issue, In this patch we have
>> fixed some issues with 'onUpdateTreeNode' function to handle some corner
>> cases for server & server-group nodes, Current code for 'onAddTreeNode',
>> 'onUpdateTreeNode', 'onRefreshTreeNode' functions for browser tree is
>> coupled with their respective inner function calls and recursive in nature
>> due to aciTree API implementation for making function calls in orderly
>> manner.
>>
>> @Ashesh,
>> Any thoughts on this?
>>
>
> I'm obviously not Ashesh, but in general, I agree with what Joao suggests
> - treeview related code should be refactored into testable modules, that
> are independent of the tree (for the most part) whenever it makes sense to
> do so, and tests added to aid future replacement of aciTree/Backbone. That
> said, if it's not feasible in a given case, then we should go ahead and fix
> the existing code.
>
> In this case, I'm leaning towards the view that this code is too tightly
> coupled with aciTree to be worth changing more than necessary. What do you
> guys think?
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Shirley Wang 2017-05-18 15:36:13 Re: Declarative partitioning in pgAdmin4
Previous Message Neel Patel 2017-05-18 14:42:17 [pgAdmin4][runtime][patch]: RM#2398 - Proxy not bypassed for embedded server in runtime on Windows