Best practice: Have SelectItem or ComboBoxItem transport additional data to the server

[Isomorphic]

Best practice is to introduce a field with customSQL="true" and use customFields to cause your additional field to appear in the SELECT and WHERE clauses for just the one operation. The problem is that you *also* tried to use customSelectExpression, and it did what it is documented to do.. but that defeats the purpose of the other two settings.

[Blama]

Hi edulid,

you can still remove the criteria serverside prior execute() or use the notEquals Operator for the request.
But I'm also interested in the official best practice here.

Best regards
Blama

[edulid]

Hi Blama

removing customSQL and customFields, I get the same results. This makes sense, since these are only there to use the field with only one operationBinding. If I remove this, it does the same.

Yes, LOWER(null) just a replacement of the field with customSelectExpression, which is the definition of "customSelectExpression". So this seems right. But then customSelectExpression="null" does not work in the case you use the criteria in your operationBinding...

So-> Which is then the correct way to pass a value to the server ?
In my other thread I have 3 approaches (one of these is customSelectExpression="null"), none of which is working as I expected. I am waiting for Isomorphic 's response on this.

[Blama]

Hi edulid,

My usecase is a bit different. I only need this to transfer data to the serverside.

• I do not use customSql, only customSelectExpression
• In my server side DMI I read the criteriaValue of that field
• I never execute the incoming dsRequest in my server DMI - I only need the data and do other requests (therefore I don't have the LOWER(null)='abc'-problem you are seeing
• I return the DSResponse from a handcrafted request

Your generated SQL does look OK to me. ((LOWER(null)='abc')) is your ($defaultWhereClause). And it's LOWER(null) because of your customSelectExpression and the request being ingnoreCase.

Best regards
Blama

[edulid]

Hi Blama

I made a simple test case with this approach, but something seems not to work well. Are you using customFields="FAKECOLUMN" in your operationBinding ?

Here my testcase:

1 Testcase:

<DataSource ID="minimalTestcase" serverType="sql" tableName="minimalTestcase">
    <fields>
        <field name="FAKECOLUMN" type="text" customSelectExpression="null" customSQL="true" />
        <field name="f_id" type="integer" primaryKey="true" />
        <field name="f_lastname" type="text" />
        <field name="f_firstname" type="text" />
    </fields>

    <operationBindings>

        <operationBinding operationType="fetch"
            customFields="FAKECOLUMN">
            <whereClause><![CDATA[
              $defaultWhereClause
           ]]></whereClause>
        </operationBinding>

    </operationBindings>

</DataSource>

public DSResponse doCallServer(DSRequest dsRequest, HttpServletResponse servletResponse, RPCManager rpcManager) throws Exception {

        System.out.println("doCallServer");

        DSRequest fetchRequest = new DSRequest("minimalTestcase", DataSource.OP_FETCH, rpcManager);
        fetchRequest.setCriteria("FAKECOLUMN", "abc");

        fetchRequest.execute();

        return new DSResponse();
    }

The sql created:

SELECT null AS FAKECOLUMN, minimalTestcase.f_id, minimalTestcase.f_lastname, minimalTestcase.f_firstname FROM minimalTestcase WHERE 
      (LOWER(null)='abc')

This sql seems incorrect. You are setting your criteria values with "setPickListCriteria(new AdvancedCriteria("FAKECOLUMN", OperatorId.NOT_EQUAL, valueToTransmit)))", but this should have the same effect ?

2. Testcase:

If I change my operationBinding definition (leaving everything else exactly the same) to:

<operationBinding operationType="fetch"
            customFields="FAKECOLUMN">
            <whereClause><![CDATA[
              $advancedCriteria.FAKECOLUMN = 'abc' and ($defaultWhereClause)
           ]]></whereClause>
        </operationBinding>

I get this sql:

SELECT null AS FAKECOLUMN, minimalTestcase.f_id, minimalTestcase.f_lastname, minimalTestcase.f_firstname FROM minimalTestcase WHERE 
      'abc' = 'abc' and ((LOWER(null)='abc'))

This sql will never return a row. But, since my criteria value is 'abc' and I compare this criteria value with 'abc', this should return columns... or ? Isomorphic is this a bug ?

Using smartgwt 6.1p power 2018-03-28

[Blama]

Hi Isomorphic,

OK, thank you.

Best regards
Blama

[Isomorphic]

If a change in this field changes what is returned from the server, then it is in fact criteria. There is also no reason to consider the field fake, since, although it is not persisted, it is a field used as criteria, and the field's type and other details potentially affect what the framework does with it, so that declaration is quite necessary.

[Blama]

Hi Isomorphic,

I have the requirement that a DataBound ComboBoxItem or SelectItem transfers additional data to the server with it's fetch request for the picklist.
That data will be used for DMIs that in the end return the request picklist data.

What's the suggested approach for this?

Right now, I'm using a fake DataSource field in my optionDataSource for this:

<field name="FAKECOLUMN" type="integer" customSelectExpression="null" />

and add fake criteria to the item:

setPickListCriteria(new AdvancedCriteria("FAKECOLUMN", OperatorId.NOT_EQUAL, valueToTransmit)))

In the serverside I get the criteria via

request.getCriteriaValue("FAKECOLUMN")

This works, but is this really the best approach?

Thank you & Best regards
Blama