Re: Regarding issue 1241 - Mailing list pgadmin-hackers

From Dave Page
Subject Re: Regarding issue 1241
Date
Msg-id CA+OCxoy+w5PKJ1jgq-+QigONn7=hZHPHsUtOJ=u=p1Eabc-o2w@mail.gmail.com
Whole thread Raw
In response to Re: Regarding issue 1241  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
Responses Re: Regarding issue 1241  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
List pgadmin-hackers
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


pgadmin-hackers by date:

Previous
From: Ashesh Vashi
Date:
Subject: Re: Regarding issue 1241
Next
From: Ashesh Vashi
Date:
Subject: Re: Regarding issue 1241