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

    Rejecting enetered text in ComboBoxItem with addUnknownValues == false

    Hello Isomorphic,
    I attempt to achieve following behavior at ComboBoxItem with addUnknownValues == false. When user input does not match any option, I need user enetered text to remain in place and user to be forced to stay in the field until value is corrected or "ESC" is explicitly pressed to revert to original value. Desirably some special CSS styling to be applied to an invalid text. Alternatively, some hint text or even message could be shown to user. This request is relevant for both ValueMap and DataSource - bound combo boxes. I'm digging through documentation and source code and do not find how to implement such behavior. Could you please direct me?

    We'd recommend against implementing that UX. Because of the inherently asynchronous nature of the server trip to check if the value already exists, you're going to end up yanking focus back to the field when the user has started on the next field, or just have to block the whole UI for the duration of the server check. Both possibilities are really annoying.

    That said, if you want to head down this path, the only way to block a user from leaving the field is to just force focus back to the field if they try to exit (so use editorExit and focus()).


      I understand that. Focus is my least problem. The bigger problem is that when user types in incorrect value, this value just silently replaced by original value (the one that was there before last field change). What I'm looking for is:

      1. Have addUnknownValues = fase, so that illegal values are not getting into data form / ValuesManager
      2. If user attempts to accept illegal value (i.e. exit from field), notify through applying special CSS (i.e. having red wave line decoration), showing hint or warning balloon
      3. OPTIONALLY get focus back to this field. And yes, I'm willing to agree with you may be better idea to give up on this because of bad UX

      So the really problematic issue is #3 - how to leave typed in text in-place (and highlighted somehow) while having value in it's correct state


        Hi nick.shrayer.2,

        would something like addUnknownValues=true + validateOnExit=true + rejectUnwantedValuesInDMIValidation work?

        Best regards


          What is rejectUnwantedValuesInDMIValidation ?

          Also, I would really like to see such behavior as an option for standard ComboBoxItem. In case addUnknownValues=true, there is always a chance invalid value (i.e. free text instead of GUID) getting into ValuesManager



            I meant defining a custom server validator in your .ds.xml for the field in question and returning false for display-values not in the optionDataSource.
            I agree that this is a workaround and that your requested behavior sounds reasonable as optional behavior.

            Best regards


              Validation on server side is not an option. Server side knows about this field as being GUID and so does not accept free text for validation. It's pure client task to be able to map between entered text and GUID. And it does so but the behavior of silently reverting incorrectly typed text into previous value is something that does not look reasonable.

              So Isomorphic, could you please provide your thoughts?


                Blama's suggestion is appropriate, and your objection to it doesn't make sense to us. You are using a DataSource here, so clearly you are sending search strings to your server which the server matches to records. Hence you *must* already have the ability to check whether a search string matches a record or you couldn't implement this interaction at all.


                  Also, if perhaps you are loading the entire dataset client-side and that's why you say your server can't perform this validation, then you could validate the value client-side, so again, the approach is totally feasible.


                    Dear Isomorphic,
                    your assumptions are incorrect. Let me explain this by example.

                    You have a "ReferencedData" DataSource with fields "Id" (type GUID on server, string on client) and "Name" (string)
                    You have a "MainData" DataSource having "SomeDataId" field (type GUID on server, string on client, foreignkey to DS "ReferencedData")

                    Ineeded, "ReferencedData" DS known to search against string ("Name" field) and resolve name to ID. But server is unable and is not expected to be able to get some arbitrary text as value for "SomeDataId" field of "MainData" DS. This field is expected to be valid GUID when arriving to server side. What Blama suggests is to allow SmartClient to leave unvalidated free text as part of "SomeDataId" field and then validate on server that this text could not be resolved into ID. But it's pure client task to make this resolution (and validation) and this is what SmartClient correctly does in case of addUnknownValues=false.

                    My request is to have the possibility to always or based on some flag not to silently revert unknown value into previous one but to leave UI form item in "Pending" state and somehow mark typed in value as incorrect.I understand that this could be treated as an RFE. In this case could you please estimate what would be the cost of this. For me this really looks like show stopper


                      With addUnknowValues:false, the framework achieves the resolution from Name to ID *by sending a request to the server*. In the suggested validation approach, you are on the server, so you have the opportunity to do the same kind of processing.

                      This is so very very normal and typical that it is a built-in validation type in the SmartClient server (hasRelatedRecord).


                        Note that your proposal for an RFE for this to "mark the value as incorrect" is effectively the same as a validation error, which the approach we are already recommending and works the same way (a server trip to check if the record exists), so it would just be "reinventing the wheel".


                          Please see my explanation talking about "ReferencedData" and "MainData" data sources. When sending request to the server for resolving Name to ID, the request is done in context of "ReferencedData" DS. So it's perfectly valid to pass some incorrect string as "Name" to be resolved and to get response "Thsi text could not be resolved". On the contrary, having addUnknownValues: true allows unresolved text to fall through directly into the "SomeDataId" field which is expected to be valid ID. This field never gets names. Only IDs. So in case resolution is made (i.e. user typed in correct value or chosen something from combo list), the SomeDataId gets ID. And in case resolution is not made, same SomeDataId field gets unresolved text. My RFE is about having this unresolved text on FormItem enteredValue level only AND NOT PASSING it back to ValuesManager until it's resolved into ID. The field which is ID should always get ID and never free text. Am I clear in explaining the problem?


                            When you receive, on the server, some kind of free text that is not a valid ID for a related record, that's when you reject it as a validation error.

                            We're not sure how this is not being understood. Are you trying to assert that it is *impossible* for the server to figure out that the value it has been passed is not a valid ID? That obviously cannot be the case, since the client side can tell, just by contacting the server!


                              Of course this could be somehow done by server. But current server infrastructure just does not expect to get free text for the field which is defined as GUID. The "validation" error which server returns (and should return in this case) is like "String '...' could not be treated as GUID". And this is obviously not the error that should be given to user. Again, it's possible to get what I need by tweaking and workarounds and ugly tricks. But SmartClient infrastructure is powerful enough and provides so much great features that I don't feel good with applying those tricks instead of having proper solution on client side. Obviously, client is able to detect the problem and stop user from submitting erroneous data