Announcement

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

  • stonebranch2
    replied
    :) Thank you for the clarification.

    Leave a comment:


  • Isomorphic
    replied
    Oh, we see where the confusion is coming from. You see, we actually use DataSources called Component Schema to describe our own components. Specifically, the XML format for defining DataSources is expressed as a DataSource. In that DataSource, the field "validOperators" is declared and it is considered a multiple:true field because it has an array value.

    As far as having multiple:true fields in your application DataSources, that's not relevant to how XML for validOperators is parsed - totally different layer. So nothing to worry about there.

    Leave a comment:


  • stonebranch2
    replied
    I just don't know what you mean by "For 13.1 we plan to make both formats work for all multiple:true fields.".

    We have fields, designated "multiple:true", that use <validOperators>.

    For example:

    Code:
    <field name="xxxx" foreignKey="xxx.xxx" displayField="xxxx" type="text" multiple="true" length="2048">
                <validOperators>isNull</validOperators>
                <validOperators>notNull</validOperators>
                <validOperators>iContains</validOperators>
                <validOperators>iNotContains</validOperators>
    </field>
    I assume for 12.1, with the next build, will work?

    Thanks

    Leave a comment:


  • Isomorphic
    replied
    How do you mean?

    To clarify, the only field involved here is validOperators - it didn't actually support the documented XML format, but an undocumented format happened to work (which you chanced upon). So we fixed it, and then the fix broke your undocumented usage, and now we've modified how that one field is processed so that both the documented and undocumented format will work. No other fields are affected.

    Leave a comment:


  • stonebranch2
    replied
    Thank you,
    For 12.1, we have multiple:true fields that are impacted. Will your fix apply to those?
    Thanks,
    Jeremey

    Leave a comment:


  • Isomorphic
    replied
    We've committed a narrow fix for validOperators to work with both the undocumented and documented formats, for 12.1. This commit didn't quite make the daily build deadline, so you want tomorrow's (Thursday's) build.

    For 13.1 we plan to make both formats work for all multiple:true fields.

    Leave a comment:


  • stonebranch2
    replied
    Thank you very much.

    Leave a comment:


  • Isomorphic
    replied
    Understood. We'll put in code to handle the old, undocumented format right away.

    Leave a comment:


  • stonebranch2
    replied
    Note also, since basically every DataSource was broken for you, we’re guessing you probably have validOperators declarations in just about every file - you don’t need to do that. See the linked thread for how to use SimpleType so that you can share validOperators (and other field configuration).
    We only use this declaration for verify specific fields, not globally for every field type. For example, foreign key fields, as shown in the example above.

    We do not use it globally for every field.

    Leave a comment:


  • stonebranch2
    replied
    Hi Isomorphic,

    Thank you for the update.

    Please let us know when you have a build available that is backwards compatible with the format we are using. For our current maintenance release, we are limiting the scope of changes, so we will have to review the additional information you provided and consider it for a future release.

    Thank you

    Leave a comment:


  • Isomorphic
    replied
    Ok, we figured this out. Someone tried to use the documented format for validOperators, and it didn’t work, so we fixed it:

    https://forums.smartclient.com/forum...ile#post268106

    It looks like you figured out an undocumented format that worked before we corrected the bug, but doesn’t now.

    The best thing would be to switch to the documented format, but, because other people may have figured out the undocumented format you did, we do plan to make both work, but that will take a few days.

    Note also, since basically every DataSource was broken for you, we’re guessing you probably have validOperators declarations in just about every file - you don’t need to do that. See the linked thread for how to use SimpleType so that you can share validOperators (and other field configuration).

    Leave a comment:


  • stonebranch2
    replied
    No, the server side log shows no indication of anything going wrong.

    I created a scaled down version of one of the ds.xml.

    Code:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <DataSource xmlns:fmt="WEB-INF/" ID="userPreference" inheritsFrom="system" serverType="generic">
        <fmt:bundle basename="dictionary"/>
        <fields>
            <field name="userName" type="text" opsFkRefField="userId" canEdit="false">
            </field>
            <field name="userId" foreignKey="user.sysId" displayField="userName" type="text">
                <validOperators>iEquals</validOperators>
                <validOperators>iNotEqual</validOperators>
                <validOperators>isNull</validOperators>
                <validOperators>notNull</validOperators>
                <validOperators>inSet</validOperators>
                <validOperators>notInSet</validOperators>
            </field>
        </fields>
    </DataSource>
    Click image for larger version

Name:	Screenshot 2022-06-10 221438.png
Views:	49
Size:	7.8 KB
ID:	268179

    Leave a comment:


  • Isomorphic
    replied
    One more question: are you seeing any warnings or other server side logs when you hit the DataSourceLoader and get a bad result which might shed light on what's happening?

    Thanks

    Leave a comment:


  • Isomorphic
    replied
    From what you've shared so far it seems like when the dataSourceLoader URL is hit, it's failing to pick up the validOperators XML elements and turn them into JS.
    To verify this, can you do the following:

    - open the browser inspector / developer tools and open the Network tab
    - kick off the code that calls "getDataSource()" and watch for the request that hits the "DataSourceLoader? ..." URL
    - Look at the contents of the server response. If the "validOperators" attribute of a field is indeed just validOperators:iEquals or whatever, that's invalid JavaScript [as the iEquals isn't a quoted string or an array].

    You mention that this is happening for multiple DataSources. Presumably multiple DataSources are not actually required to hit the problem though.
    You should be able to pick any of these and confirm this is indeed the problem by hitting the dataSourceLoader url with a suffix of "?dataSource=<dsName>" and looking at the output.

    Can you confirm that this is indeed what you're seeing.
    If so - can you share the full ds.xml file with us [feel free to mail it to support@isomorphic.com if it's not appropriate to be shared on a public forum].

    We're not reproducing this issue on our end so it seems there must be something special about your dataSources.

    Thanks
    Isomorphic Software

    Leave a comment:


  • stonebranch2
    replied
    There are also occurrences for other operators too, like iContains, for example.

    Leave a comment:

Working...
X