Announcement

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

    SelectItem field needs to call option data source prior

    Scenario: A filterbuilder uses a datasource that contains datasourcefields in which the editorType is set to "selectitems". The "selectitems" in turn are set to use a MySQL datasource in which there are two columns, one for the actual "valueField" and one for the "displayField". (And though it's irrelevant, the valueField is defined as a float.) The filterbuilder is created programmatically to have some fileters set using the "valueField" as follows:

    Code:
    criteria = new AdvancedCriteria(OperatorId.AND, new AdvancedCriteria[] {  
    				
    					new AdvancedCriteria("group_probability", OperatorId.GREATER_OR_EQUAL, "0.20"),
    				 });  
    			}
    The Problem: The user will not see the value of "0.20" selected in the selectItem. Instead it's blank. However, if the user actually clicks on the "drop down arrow" in the selectItem, then the selectItem refreshes and correctly displays the "displayField" associated with the value of 0.20.

    How can I get the selectItem to correctly display the "valueField"? I'm assuming that I need to somehow get the selectItem to make a "fetch" once it gets drawn, instead of requiring the user to click on the "drop down" button, but I couldn't determine how to do this.

    Additional details:
    ======================
    SmartGWT (not smartclient) Version: SmartClient Version: v8.3p_2012-11-26/PowerEdition Deployment (built 2012-11-26)
    ...
    Browser: Mozilla Firefox ESR 10.0.7
    GWT SDK: 2.5.0rc2
    Sun JDK 1.6.0_13
    OS: Centos 6.x
    IDE: MyEclipse 10.6 with Google Plugin for Eclipse (3.1.0)

    #2
    The FormItem.fetchMissingValues behavior should cause an automatic fetch to the server with criteria asking for the Record that has value for the valueField "0.20". Your DataSource may not be responding to this request correctly - you can use the RPC tab in the Developer Console to see what's going on.

    If you think it might be a framework bug instead, please provide runnable code so we can see the problem - you could take any Showcase FilterBuilder sample and add in a custom SelectItem with an optionDataSource set to one of the DataSources in the Showcase, for example.

    Comment


      #3
      Based on the reply provided and further experimentation, I (think) I've isolated the problem to the situation when the selectitem only pulls the first 75 records (due to paging). (The problem dissapears if my lookup table has only 2 or 3 rows.) Since I want to disable paging anyways on these selectitems, I thought I try the "disable paging" tecnique. But, no matter what I tried, I couldn't disable paging on these selectitems -- it's almost as if my settings get overriden by the default behaviour of "selectItem". This is what I tried.

      In the datasource, I tried this:

      Code:
      <DataSource ID="dstm_percentages" dataFormat="iscServer" showPrompt="false"  
      serverType="sql" dataSourceVersion="1" dbName="Mysql" tableName="tm_percentages" sqlPaging="NONE">
          <fields>
              <field name="tm_percentages_key" type="integer" required="true" hidden="true" primaryKey="true"/>
              <field name="percentageAsDecimal" type="text" required="true"/>
              <field name="percentageAsString" type="text" required="true" length="4"/>
          </fields>
          
          
          <operationBindings>
      
      		<operationBinding operationType="fetch"  sqlPaging="NONE"/>
      			
      
          </operationBindings>
          
          <generatedBy>SC_SNAPSHOT-2011-09-26/EVAL Deployment 2011-09-26</generatedBy>
      </DataSource>
      Note: I tried to add the "sqlPaging="NONE" in both the operationBinding section as well as right at the top part.

      That didn't work, so I also added these entries to the server.properties file:

      Code:
      sql.defaultCustomSQLPaging="NONE"
      sql.defaultPaging="NONE"
      And in the part where I define the datasource programmatically, I added the "setAllCacheData" to true.

      Code:
      selectItem.setDisplayField(displayField);
      					selectItem.setSortField(valueField);
      					DataSource dsOptionDataSource= DataSource.get(currentDataSourceField.getAttributeAsString("iaDSOptionDataSource"));
      
      // **************					dsOptionDataSource.setCacheAllData(true);			
      // ***************
      		selectItem.setOptionDataSource(dsOptionDataSource);
      However, in all cases, I could tell from the SC Developer Console that it was paging. How do I shut off paging for "selectItems"? (I have no troulbe controlling paging behaviour for listgrids, since there's a specific method I can set in those cases.)

      Comment


        #4
        FYI: I also tried using the lowercase word "none" insted of "NONE'. But that didn't help either.

        Comment


          #5
          Set selectItem.filterLocally to disable data paging.

          You probably do not actually want to disable data paging, but instead investigate the actual problem based on the previously provided advice.

          sqlPaging has a completely different function which doesn't apply here. You can read about what it does in the documentation.

          Comment


            #6
            Thanks, this helped.

            That said, I believe I narrowed it down the problem.

            It has nothing to do with paging. That was a red-herring. It turns out that I get the above mentioend problem when the underlying MySQL table has for it's "code" field a FLOAT. For some reason, that causes the problem described above. I chagned it temporarily to a string (even though that's not quite right) and the problem dissappeared. I believe, therefore, there's a subtle bug with the filter-builder interface if the following conditions are met:

            1) the underlying MySQL table has the "code" field as a float.
            2) the datasource definitions correctly refer to this code field as a float (see code snippets earlier in this thread)
            3) The filterbuilder has a predefined advanced criteria in which one of the conditions specifies a STRING instead of a float (see code snippets earlier in this thread). Note: If I change the criteria to use a "float", as follows, it also fails to work.

            Code:
            new AdvancedCriteria("group_probability", OperatorId.GREATER_OR_EQUAL, 0.20f),
            				 });
            In fact, when specifying it as a float, it's worse, since manually clicking on the drop-down does NOT cause the user interface to correctly pick up the "20%" value at all. So, for now, my "hack" is to change the underlying MySQL table definition to use "char(4)" instead of "float". (Note: I tried setting the MySQL "code" field decimal(3,2), but that didn't work either.)

            For now, my "hack" works, but it's not quite correct, since "floats" don't sort the same way as "strings" etc.

            Comment


              #7
              Providing a String as criteria against a DataSourceField of type "float" is definitely wrong (regardless of table definition or storage model).

              You haven't specified what went wrong when you provided the criteria in the expected format.

              If you think there's a framework issue here, we'll need to see a minimal, ready-to-run test case clearly demonstrating a framework problem.

              Comment


                #8
                I'll try to create a test case. I suspect the issue is that a float of "0.20" does not translate to EXACTLY 0.20 in javascript, but something close to 0.20 (eg 0.1999923123). When we pull from the MySQL db, though, maybe a float of 0.20 becomes exactly 0.20....Not sure, will try to create a test case.

                Comment

                Working...
                X