Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    SC10.1 FilterEditor defaultValue regression from 9

    I have just upgraded from SC9 to 10 and found a difference in the way the FilterEditor on a ListGrid behaves from version 9. It seems to be in all the nightlies of 10 that I've tried, ranging from the earliest available up to the latest:

    SNAPSHOT_v10.1d_2014-10-27/Pro Deployment

    I have observed this using Chrome 38 on Windows and OSX.

    To re-create:

    1. Open http://smartclient.com/#dataSourceFields

    2. Modify fieldsDS.js to showFilterEditor:true and click 'Try it'

    Code:
    isc.ListGrid.create({
        ID: "countryList",
    showFilterEditor:true,
        width:500, height:224, alternateRecordStyles:true, 
        dataSource: countryDS,
        autoFetchData: true
    })
    3. Modify countryDS to set defaultValue:"US" for countryCode and click 'Try it'

    Code:
    isc.DataSource.create({
        ID: "countryDS",
        fields:[
            {name:"countryName", title:"Country"},
            {name:"countryCode", title:"Code",defaultValue:"US"},
            {name:"independence", title:"Independence", type:"date"},
            {name:"population", title:"Population", type:"integer"},
            {name:"gdp", title:"GDP ($B)", type:"float"}
        ],
        clientOnly: true,
        testData: countryData
    })
    You will see 'US' as the defaultValue in the FilterEditor item for country code.



    In SC9 this did not happen.

    If you now type 'China' in Country and press enter, not surprisingly it says 'No items to show'. However, if you then tab to the Code field and try to delete US and then press enter, 'US' re-appears in the filtereditor BUT the China row shows up in the grid.



    I investigated trying to use ListGridField.defaultFilterValue to counter-act the defaultValue and whilst that would set the initial value of the box, subsequently US would re-appear if you cleared the box.

    I also observed further difficulties when using fields of type Boolean or with valueMaps.

    For boolean fields, a defaultValue of, say, true, means that the filter box is checked. In SC9 it would have been in the 'don't care' state. It does not seem possible to set a defaultFilterValue of 'don't care'. I tried null and undefined but they seemed to be overridden by the defaultValue of true. Although by manually clicking the box, it is possible to cycle all options of 'True' 'Don't care' and 'False'.

    For valueMap'ed fields, it seems that you can't select the 'no value' option for the FilterEditor. The moment you press Enter to search, it will go back to the default value.

    These last cases with the boolean and valueMap'ed field can be played with by further modifying countryDS. Although I have not set out the steps particularly carefully because I feel that the first part of this description is sufficient to fully illustrate the problem.

    Code:
    isc.DataSource.create({
        ID: "countryDS",
        fields:[
            {name:"bool", title:"Bool",type:"boolean",defaultValue:true,defaultFilterValue:null},
            {name:"valMap", title:"valMap", valueMap:{a:"A",b:"B"},defaultValue:"b"},
            {name:"countryName", title:"Country"},
            {name:"countryCode", title:"Code"},
            {name:"independence", title:"Independence", type:"date"},
            {name:"population", title:"Population", type:"integer"},
            {name:"gdp", title:"GDP ($B)", type:"float"}
        ],
        clientOnly: true,
        testData: countryData
    })
    Given that the new behaviour appears to exhibit some fundamentally broken traits I feel this is a regression from SC9 rather than just a new behaviour in SC10.

    I look forward to your comments! I'm happy to expand on my use case or provide further examples. In our actual application, we have more complex set up's, with dependent drop-downs that are also broken by this regression in behaviour; however, I reckon those will start working again if the underlying problem is addressed.

    Thanks

    Edward Sharp

    PS I should add that I do need to set a defaultValue for various fields at the DataSource level, so that when new records are created from different places within the application, the correct defaultValue's for the new records are set.
    Attached Files
    Last edited by Osirium1; 27 Oct 2014, 02:46.

    #2
    This is blocking us from upgrading to SC10. Isomorphic, have you had a chance to look at this?

    Thanks

    Edward Sharp

    Comment


      #3
      defaultValue is not a valid setting on DataSourceField (see docs).

      Your attempt to set defaultValue on DataSourceField no specified behavior (for any version), so you should look at adjusting your code to use documented properties instead.

      Comment


        #4
        Thank you for replying promptly. I accept that our use case is undocumented, although it has conveniently worked in every SmartClient version since 7.0 when we started using it.

        I propose the DataSourceField should be enhanced to allow a defaultValue.

        Our use case is that there are multiple mechanisms for making a new 'x'. Sometimes you make it inline in a ListGrid and other times via a DynamicForm. In either of our cases, the defaultValue's are common, regardless of the mechanism.

        Whilst I can make a function to generate sets of fields that include the defaultValue for visual components, but not for datasources, I liked that the datasource was the one common source for the definitions.

        Would you consider this as:

        a) a valid enhancement?
        b) will you say it's a feature sponsorship? or
        c) propose a better alternative?

        Thanks in advance.

        Edward Sharp

        Comment


          #5
          It would be a valid Feature Sponsorship to have a DataSourceField.defaultValue property added for a future version.

          Part of the process of implementing such a property would be to spell out exactly what it does. You say you want it to work for ListGrid and DynamicForm, well, that's what it's doing: the FilterEditor is a DynamicForm, so it appears there. It was a happenstance of initialization order that made it apply or not apply to the FilterEditor in previous versions of SmartClient.

          To make dataSourceField.defaultValue into a coherent, supportable feature we'd probably add other properties that controlled either what DBCs it applies to, a second property dataSourceField.defaultFilterValue, or similar.

          Comment


            #6
            Okay - we'll consider that. Thanks.

            Comment

            Working...
            X