Re: Regarding issue 1241

On Wed, Jun 15, 2016 at 2:08 PM, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com
> wrote:

> On Wed, Jun 15, 2016 at 6:25 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> On Wed, Jun 15, 2016 at 1:49 PM, Ashesh Vashi
>> <ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>> > On Thu, Jun 2, 2016 at 1:59 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, May 31, 2016 at 8:53 PM, Harshal Dhumal
>> >> <harshal(dot)dhumal(at)enterprisedb(dot)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!
>>
> 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