Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDBnm-00008Y-TM for pgadmin-hackers@arkaria.postgresql.org; Wed, 15 Jun 2016 14:28:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bDBnl-0008CX-T5 for pgadmin-hackers@arkaria.postgresql.org; Wed, 15 Jun 2016 14:28:17 +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 1bDBnk-0008CO-Uj for pgadmin-hackers@postgresql.org; Wed, 15 Jun 2016 14:28:17 +0000 Received: from mail-it0-x230.google.com ([2607:f8b0:4001:c0b::230]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bDBnh-0005qo-GA for pgadmin-hackers@postgresql.org; Wed, 15 Jun 2016 14:28:15 +0000 Received: by mail-it0-x230.google.com with SMTP id i6so20093240ith.0 for ; Wed, 15 Jun 2016 07:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M0IktBv5AU9HD/1c8ffc3SGP26jK/f6BoCXKK1+/t8g=; b=lUk6ZRpVTj7Gdc5N8nkXQlI9L/C1hD1IZ0gALEJ09dpAS1HOVN+QkwmAWT/3JtGzO9 mTz/m6asB2WxJB9GdoZJ8RsomCxlmR6gbwpeobhNR56gY0FaTAyQ5rjVsjrQD3QzImHi lYuYlwl59gBpK+pJ4nZUpJN/G03mE5VMzmYgW3lPw0ERE7ZMpvr47Qp/dEKWqT5/RgIN TktG6Re0TWIVwVwibbTmXSreBh5JomFnjZmEi4tKvztAotAd/KB2RZvZyBidJe1evq8d 3aZP+QrRUW34qJYnVLYq7nlH+ca0WUQFA2sT5AhUXiriyVKMgfmz4nkQ5pDPxjTDLyfm TICg== 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=M0IktBv5AU9HD/1c8ffc3SGP26jK/f6BoCXKK1+/t8g=; b=h6PNBs08vN9fQWlf82FNJUSE/JMu/QkerPATimXyQIsyro888EyZ1ZeAlNrigZ628J sYlgMYPr21VpddSUhpaPInLXdjfLk+elqqEe/d8+G9/zTQZLPL6CuFJZUbA1HrbGABVw J7jrZivaClw54UVbnbY4KYhTkuJR569ZMMuLZtUuB2/x4Uceg8Zd2z6znAn5w0qFv9o1 87ohLyij2yGIiFXwN+nyZ+bJagtNTzVUjAHmYli5CDXOVGBIBcfmfzXt6aBmzY+C2aiD koJBiHZrJYWx6wnr7ce+1/voAfU9dZCJcaqDXQmGVgao9MZ+xzjc3ZT6WrvWpIs+beCU +scA== X-Gm-Message-State: ALyK8tKJK/kqjZ7i2FeBXYI3KQ2UiYT6ik06mol0UDwFjG5C7hLkez+3gDOY4oQeBfyRCCpY7e4OG7ZxO1nzqQwt X-Received: by 10.36.250.10 with SMTP id v10mr56245ith.25.1466000892564; Wed, 15 Jun 2016 07:28:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.217 with HTTP; Wed, 15 Jun 2016 07:27:53 -0700 (PDT) In-Reply-To: References: From: Ashesh Vashi Date: Wed, 15 Jun 2016 19:57:53 +0530 Message-ID: Subject: Re: Regarding issue 1241 To: Dave Page Cc: Harshal Dhumal , pgadmin-hackers Content-Type: multipart/alternative; boundary=94eb2c0347687128ca053551ee3f 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 --94eb2c0347687128ca053551ee3f Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 7:24 PM, Dave Page wrote: > > > On Wed, Jun 15, 2016 at 2:08 PM, Ashesh Vashi < > ashesh.vashi@enterprisedb.com> 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? > Yes - we do. It is not change in the design of the UI control, but - we will need to replace simplified subnode control (which is already present in the system), and make the validation check in each of the data model one at a time. We need to keep the UI at other place, until we fix the data validation part at each of those places. We will remove the UniqueColControl once we complete all these changes. That's why - I said it was mistake to do the validation in Control rather than the data (Backbone.Model). -- Thanks & Regards, Ashesh Vashi > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --94eb2c0347687128ca053551ee3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2016 at 7:24 PM, Da= ve Page <dpage@pgadmin.org> wrote:


<= div class=3D"gmail_extra">
On Wed, Jun 15, 2016 at 2:08 PM, Ashesh Vashi <ashesh.vas= hi@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 differ= ent UI design for this one use. Are we talking about the same thing?=C2=A0<= /div>
Yes - we do.
It is not c= hange in the design of the UI control, but - we will need to replace simpli= fied subnode control (which is already present in the system), and make the= validation check in each of the data model one at a time.

We need to keep the UI at other place, until we fix the data valid= ation part at each of those places.=C2=A0
We will remove the UniqueCol= Control once we complete all these changes.

That's w= hy - I said it was mistake to do the validation in Control rather than the = data (Backbone.Model).


--
Thanks & Regards,
Ashesh Vashi
=C2=A0

--94eb2c0347687128ca053551ee3f--