On Wed, Jun 15, 2016 at 2:08 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com > wrote:
> On Wed, Jun 15, 2016 at 6:25 PM, Dave Page <dp...@pgadmin.org> wrote: > >> On Wed, Jun 15, 2016 at 1:49 PM, Ashesh Vashi >> <ashesh.va...@enterprisedb.com> wrote: >> > On Thu, Jun 2, 2016 at 1:59 PM, Dave Page <dp...@pgadmin.org> wrote: >> >> >> >> >> >> >> >> On Tue, May 31, 2016 at 8:53 PM, Harshal Dhumal >> >> <harshal.dhu...@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! >> > 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
