Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDBGz-0006om-PS for pgadmin-hackers@arkaria.postgresql.org; Wed, 15 Jun 2016 13:54:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bDBGy-0004Ii-Rc for pgadmin-hackers@arkaria.postgresql.org; Wed, 15 Jun 2016 13:54:24 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bDBGk-0003oa-W4 for pgadmin-hackers@postgresql.org; Wed, 15 Jun 2016 13:54:11 +0000 Received: from mail-it0-x235.google.com ([2607:f8b0:4001:c0b::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bDBGh-000523-Oz for pgadmin-hackers@postgresql.org; Wed, 15 Jun 2016 13:54:09 +0000 Received: by mail-it0-x235.google.com with SMTP id z189so107311722itg.0 for ; Wed, 15 Jun 2016 06:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UUGYGT5uDKfJr6OErSVfeStlREB+xuKcBPKmNIe+u1c=; b=x3C9KBlceULMBR/lkVx1wIvNad5YscuEQ4nMTBS/nVYBc/0Gm5UL4fZvKUN5PGyAQm 8UTMpVcdO8FPSwHDNYhsu88km394UF9ZsGa+cfI3lXAYEU11IpmZ/8k1XkW5xon4qwmD y0aewJtHcPprWOy80Tn8KoJy1aoH1iGKaDHKZ0tgD9EHP+I+o6QJT+1q98j/3U7hlEkH /Mgi/woFTH9SFz9xJ4BiZNQuyPEmRCuxoi3N/rO/lpUQCbpysfjxYVQQiVtTtSRx3W5O 5n09UxK2Dymp4HM8Xv8uyegRRILVjJW7ATfP1IvN1mt41HJs3veMB1j7f2QTUuon1cl3 iopg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UUGYGT5uDKfJr6OErSVfeStlREB+xuKcBPKmNIe+u1c=; b=MJaOOBqMDUCtHGohM/NhxPJRJfBIgS0dqwkBn+Mh2d5S000ZiVWWnWzNgjhRu6W1Ug offkvzb6dKcr4g9n/rQHUgED+wYIDp9WV6sI2pUmrTASmzwKLhLhr0FTwcXcLNqSGJlO N4QBSMbXaWdNSKJc9T337w9npkVZBV42p5ffCHYxuNjvD+RQ/sMhvnyCByz1rrgSeLTC 7469YSvlZk3rLHKDhnJ6HWr2e4kJh7M1ZCDOnn+SCr6H6se2FX970uG1j6awzVi1lbfB ouuWACThHSNha7+Tr5chSSgQmj3ZGY6UF4QOQC76N2cjSUJKfxuVO7TZ3FOi4RqcX5mb t4lQ== X-Gm-Message-State: ALyK8tIUwI37Jk54LP3wapRZthYEXvJfyifKvaNpfxZInZ+G63t6ke+gyKcy2+MzZOlmYAA8bPIQAbFm/v2qYw== X-Received: by 10.107.175.97 with SMTP id y94mr3800061ioe.70.1465998846604; Wed, 15 Jun 2016 06:54:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.233 with HTTP; Wed, 15 Jun 2016 06:54:05 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Wed, 15 Jun 2016 14:54:05 +0100 Message-ID: Subject: Re: Regarding issue 1241 To: Ashesh Vashi Cc: Harshal Dhumal , pgadmin-hackers Content-Type: multipart/alternative; boundary=001a114494b27e522205355174bf X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a114494b27e522205355174bf Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 2:08 PM, Ashesh Vashi wrote: > On Wed, Jun 15, 2016 at 6:25 PM, Dave Page wrote: > >> On Wed, Jun 15, 2016 at 1:49 PM, Ashesh Vashi >> wrote: >> > On Thu, Jun 2, 2016 at 1:59 PM, Dave Page wrote: >> >> >> >> >> >> >> >> On Tue, May 31, 2016 at 8:53 PM, Harshal Dhumal >> >> wrote: >> >>> >> >>> Hi Dave, >> >>> >> >>> Regarding Issue 1241: >> >>> >> >>> We have added header section for parameter tab deliberately so that we >> >>> can force user to select parameter name (and therefore parameter's >> data >> >>> type) before adding new row. This is required because behavior of >> second >> >>> cell (Value cell) is dependent on what parameter name user has >> selected in >> >>> first cell (Name cell). See attached screen-shot. >> >>> >> >>> For example: >> >>> 1. If user selects parameter 'array_nulls' then value for this should >> be >> >>> either true or false (and hence switch cell). >> >>> 2. If user selects parameter 'cpu_index_tuple_cost' then value for >> this >> >>> should be Integer (and hence Integer cell). >> >>> >> >>> Without the custom header (and forcing user to select parameter) we >> >>> cannot decide what type of cell we need in second column. >> >>> >> >>> Let me know your opinion on this. >> >> >> >> >> >> We need to figure out a way to fix it. Our difficulties encountered >> >> writing code should not dictate usability compromises. >> >> >> >> In this case, something that needs some thought and maybe some tricky >> code >> >> has caused us to create an inconsistent UI workflow to side-step the >> >> problem, which is not appropriate as it leads to a poor look and feel >> and >> >> potentially confusion for the user. >> > >> > Agree - we should handle these cases gracefully. >> > We need to over come the limitation by brain storming, which we already >> > started offline. :-) >> > >> > To be honest - it is a time consuming work, and there is no quick fix >> for >> > this. >> > We can handle it as one case for each change instead of targeting all UI >> > changes as one whole problem. >> > And, we can utilize the same time to fix a lot more cases in beta 2. >> >> As far as I'm aware, this is the only case where there's a real problem. >> >> > I can ask Harshal to find out all possible places, where the similar >> changes >> > are required, and create a separate case for each (though - not without >> your >> > agreement). >> >> I don't think we need to. This one sub-node grid (parameters) is the >> only one that I've seen where we deviate from the intended design - >> and I think I've seen them all now! >> > Hmm.. > > Unfortunately - some set of columns needs to be unique in most of the > cases (where these controls are used), and the checks for the unique > dataset is done at the control side, which was wrong at our end. > And, we will need to change the model validation code to check the > uniqueness of data set at data level (through Backbone.Model) now, which > will require a lot more changes than it looks. > > For example - in table node, we have too many UniqueCollControl, which > requires these changes. > Perhaps - but I fail to see how this justifies the different UI design for this one use. Are we talking about the same thing? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a114494b27e522205355174bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 15, 2016 at 2:08 PM, Ashesh Vashi <ashesh.vash= i@enterprisedb.com> wrote:
=

On Wed, Jun 15, 2016 at 6:25 PM, Dave = Page <dpage@pgadmin.org> wrote:

On Wed, Jun 15, 2016 at 1:49 PM, Ashesh Vashi
<ashe= sh.vashi@enterprisedb.com> wrote:
> On Thu, Jun 2, 2016 at 1:59 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>>
>>
>> On Tue, May 31, 2016 at 8:53 PM, Harshal Dhumal
>> <harshal.dhumal@enterprisedb.com> wrote:
>>>
>>> Hi Dave,
>>>
>>> Regarding Issue 1241:
>>>
>>> We have added header section for parameter tab deliberately so= that we
>>> can force user to select parameter name (and therefore paramet= er's data
>>> type) before adding new row. This is required because behavior= of second
>>> cell (Value cell) is dependent on what parameter name user has= selected in
>>> first cell (Name cell). See attached screen-shot.
>>>
>>> For example:
>>> 1. If user selects parameter 'array_nulls' then value = for this should be
>>> either true or false (and hence switch cell).
>>> 2. If user selects parameter 'cpu_index_tuple_cost' th= en value for this
>>> should be Integer (and hence Integer cell).
>>>
>>> Without the custom header (and forcing user to select paramete= r) we
>>> cannot decide what type of cell we need in second column.
>>>
>>> Let me know your opinion on this.
>>
>>
>> We need to figure out a way to fix it. Our difficulties encountere= d
>> writing code should not dictate usability compromises.
>>
>> In this case, something that needs some thought and maybe some tri= cky code
>> has caused us to create an inconsistent UI workflow to side-step t= he
>> problem, which is not appropriate as it leads to a poor look and f= eel and
>> potentially confusion for the user.
>
> Agree - we should handle these cases gracefully.
> We need to over come the limitation by brain storming, which we alread= y
> started offline. :-)
>
> To be honest - it is a time consuming work, and there is no quick fix = for
> this.
> We can handle it as one case for each change instead of targeting all = UI
> changes as one whole problem.
> And, we can utilize the same time to fix a lot more cases in beta 2.
As far as I'm aware, this is the only case where there'= s a real problem.

> I can ask Harshal to find out all possible places, where the similar c= hanges
> are required, and create a separate case for each (though - not withou= t your
> agreement).

I don't think we need to. This one sub-node grid (parameters) is= the
only one that I've seen where we deviate from the intended design -
and I think I've seen them all now!
Hm= m..

Unfortunately - some set of columns needs to b= e unique in most of the cases (where these controls are used), and the chec= ks for the unique dataset is done at the control side, which was wrong at o= ur end.
And, we will need to change the model validation code to = check the uniqueness of data set at data level (through Backbone.Model) now= , which will require a lot more changes than it looks.

=
For example - in table node, we have too many UniqueCollControl, which= requires these changes.

Perhaps - but I fail to see how this justifies the different UI desig= n for this one use. Are we talking about the same thing?=C2=A0
<= div>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

E= nterpriseDB UK: h= ttp://www.enterprisedb.com
The Enterprise PostgreSQL Company
--001a114494b27e522205355174bf--