public inbox for [email protected]
help / color / mirror / Atom feedFrom: Dave Page <[email protected]>
To: Ashesh Vashi <[email protected]>
Cc: Harshal Dhumal <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: Regarding issue 1241
Date: Wed, 15 Jun 2016 14:54:05 +0100
Message-ID: <CA+OCxoyH4neh8AUyRHRc0gyeVn=x5VBb9Kvbbs77GURHB2tivg@mail.gmail.com> (raw)
In-Reply-To: <CAG7mmozn5jk=h5YFPETaWYBE47PMnuxQGxgP6t6voXsvuFLz=g@mail.gmail.com>
References: <CAFiP3vz5y_sdiH6C5vH_zFY03vjEwwqXjy0LoViVyKudBpNBLQ@mail.gmail.com>
<CA+OCxox=d7AnK4BLz75BDSW2-ovXXMMhzbD8C=jYSWOa3iDDHw@mail.gmail.com>
<CAG7mmow9Ho3b6WeOn0j1iyvs94t8FdaYk8emiwrceg_Sd9-nQA@mail.gmail.com>
<CA+OCxoy+w5PKJ1jgq-+QigONn7=hZHPHsUtOJ=u=p1Eabc-o2w@mail.gmail.com>
<CAG7mmozn5jk=h5YFPETaWYBE47PMnuxQGxgP6t6voXsvuFLz=g@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgadmin-hackers>
On Wed, Jun 15, 2016 at 2:08 PM, Ashesh Vashi <[email protected]
> wrote:
> On Wed, Jun 15, 2016 at 6:25 PM, Dave Page <[email protected]> wrote:
>
>> On Wed, Jun 15, 2016 at 1:49 PM, Ashesh Vashi
>> <[email protected]> wrote:
>> > On Thu, Jun 2, 2016 at 1:59 PM, Dave Page <[email protected]> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, May 31, 2016 at 8:53 PM, Harshal Dhumal
>> >> <[email protected]> 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
view thread (9+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Regarding issue 1241
In-Reply-To: <CA+OCxoyH4neh8AUyRHRc0gyeVn=x5VBb9Kvbbs77GURHB2tivg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox