MIME-Version: 1.0
In-Reply-To: 
 <CAG7mmow9Ho3b6WeOn0j1iyvs94t8FdaYk8emiwrceg_Sd9-nQA@mail.gmail.com>
References: 
 <CAFiP3vz5y_sdiH6C5vH_zFY03vjEwwqXjy0LoViVyKudBpNBLQ@mail.gmail.com>
 <CA+OCxox=d7AnK4BLz75BDSW2-ovXXMMhzbD8C=jYSWOa3iDDHw@mail.gmail.com>
 <CAG7mmow9Ho3b6WeOn0j1iyvs94t8FdaYk8emiwrceg_Sd9-nQA@mail.gmail.com>
From: Dave Page <dpage@pgadmin.org>
Date: Wed, 15 Jun 2016 13:55:27 +0100
Message-ID: 
 <CA+OCxoy+w5PKJ1jgq-+QigONn7=hZHPHsUtOJ=u=p1Eabc-o2w@mail.gmail.com>
Subject: Re: Regarding issue 1241
To: Ashesh Vashi <ashesh.vashi@enterprisedb.com>
Cc: Harshal Dhumal <harshal.dhumal@enterprisedb.com>,
	pgadmin-hackers <pgadmin-hackers@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgadmin-hackers-owner@postgresql.org

On Wed, Jun 15, 2016 at 1:49 PM, Ashesh Vashi
<ashesh.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 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!

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

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


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers