Referencing clientContext/internalClientContext

[danosborne]

In http://forums.smartclient.com/showthread.php?t=29681&page=3

I found that in more recent 8.3 builds clientContext had been renamed internalClientContext.

I was told "Your code should not be referencing clientContext unless you actually create one, so you should correct your code, then update" so I'm wondering how I should be doing things instead.

Currently we reference this in the validateData and transformResponse functions of RestDataSources e.g...

validateData: function (values, callback, requestProperties) {
            // Force showPrompt when validating....
            var bShowPrompt = true;
            if (requestProperties
                 && requestProperties.internalClientContext
                 && requestProperties.internalClientContext.component
                 && requestProperties.internalClientContext.fieldName) {

                // If a grid boolean field is set with canToggle (the default) and the user clicks the checkbox without
                // going into into an inplace edit smartclient calls validateData on all fields, calls RPCManager.doShowPrompt (which
                // shows our busy mouse cursor) but then doesn't actually send a validate to the server and doesn't call doClearPrompt and
                // therefore our mouse cursor doesn't get reset.
                // This is an attempt to try to detect that scenario and not switch on the prompt.
                var component = requestProperties.internalClientContext.component;

                if (isc.isA.ListGrid(component)) {
                    var field = component.getAllField(requestProperties.internalClientContext.fieldName);

                    if (field.canEdit === false)
                        bShowPrompt = false;
                }
            }

            requestProperties.showPrompt = bShowPrompt;

I haven't checked if this logic is needed with 9.1 but if so is there a different way we should be interrogating the fields within a RestDataSource request or response?

Thanks,

Dan

[Isomorphic]

The values you used to reference within clientContext we're undocumented internal details that you should not be using.

It looks like you were trying to work around something you believed to be a bug, instead, try to create a test case that demonstrates there is actually a bug like you describe.

[jason.saunders]

(I am Dan's colleague and the original coder of the use of clientContext)

I'm not sure you are with the spirit of the question that's being asked. We are not raising a bug, we're after some advice on what we should be doing if clientContext/internalClientContext should not be used.

A more specific example of where we currently use clientContext is in a DataSource transformRequest handler where dsRequest.operationType == "validate". We are handling this to add some more things into the request which require us to know which field the validate is executing against.

What is the correct way to get to the field if not via clientContext/internalClientContext in this scenario?

Many thanks for any help.

[Isomorphic]

Your validation logic should not need to know which field changed. You already receive a new set of values to validate.

[jason.saunders]

Your validation logic should not need to know which field changed. You already receive a new set of values to validate.

Don't understand. The aim is for us to modify/augment the validate message that is sent to the server with some other things specific to the server implementation (the whole point of transformRequest right?).

We are using smartclient with our own server, its not smart GWT.

Ignoring all that, I actually don't understand the logic of what you're saying anyway. Are you really saying that validation needn't know what the field is? And you seem to be presuming that all we need to know is some values, when what we actually want to do is pass some other info *about the field* in the validation message to the server.

[Isomorphic]

Validation messages are per-field, so what is preventing you from adding such information?

[Isomorphic]

Just try to be a lot more specific about your exact use case.

What we have right now is an attempt to use undocumented internals for:

1. an attempted workaround for what you perceive is a bug (but was never reported)

2. some other use case that you are being quite vague about

We can only recommend an alternative approach when we have a complete idea of the use case.

[jason.saunders]

Just try to be a lot more specific about your exact use case.

What we have right now is an attempt to use undocumented internals for:

1. an attempted workaround for what you perceive is a bug (but was never reported)

2. some other use case that you are being quite vague about

We can only recommend an alternative approach when we have a complete idea of the use case.

Forget about use cases and about alternative approaches just for a second.

How, in the transformRequest when dsRequest.operationType == "validate", do I get the field that is being validated, or more specifically the field that caused the validate request.

Some background, we are using RestDataSource. When a field on a DynamicForm is validated the validate message contains the values for all fields on the form. We don't send all fields as in our implementation the server holds the state of all fields and doesn't need to know the state of others. I therefore need to know which field is being validated.

clientContext tells me this info via dsRequest.clientContext.fieldName.

[Isomorphic]

That information is not exposed at the DataSource layer, by design. In general, validators can depend on information in more than one field, so we would regard it as incorrect not to send this information to the server.

But if you are looking for a hack, you could call DynamicForm.getFocusItem() to figure out where keyboard focus is.

[jason.saunders]

That information is not exposed at the DataSource layer, by design. In general, validators can depend on information in more than one field, so we would regard it as incorrect not to send this information to the server.

But if you are looking for a hack, you could call DynamicForm.getFocusItem() to figure out where keyboard focus is.

Our server already knows the values of all other fields so can do cross dependency checks. On that basis its a stronger argument to say its poor use of resource to send all fields values to the server when one field changes, particularly on a form with one or more textarea/richtext fields containing masses of data.

I don't think DynamicForm.getFocusItem can work as validate can be called on any field at any time, not necessarily when it has the focus.

So the question remains as far as I'm concerned, how do I know which field is being validated if I'm not allowed to use clientContext?

[Isomorphic]

Yes, validate can be called at any time, which is why there isn't really a meaningful or reliable notion of which field is triggering validation, which is our whole point: you shouldn't depend on knowing the field.

The closest thing to the field triggering validation is the focused field and we've explained how to get that.

[jason.saunders]

Yes, validate can be called at any time, which is why there isn't really a meaningful or reliable notion of which field is triggering validation, which is our whole point: you shouldn't depend on knowing the field.

The closest thing to the field triggering validation is the focused field and we've explained how to get that.

When you say "validate" here are you talking about the DynamicForm.validate which would validate all fields on the form? If so it makes sense (but also which we don't use).

If you are talking about a call to FormItem.validate (yes, at any time) which results in a dsrequest to send a validate to the server and that somehow means there isn't any notion of which field is triggering validation (and dsRequest.clientContext.fieldName holds precisely that), then that doesn't make sense.

Should I really be using a custom validator with requiresServer: true? Can this work with a non-smartgwt server? Would you be able to supply an example?

If I can't do it via a custom validator then I seem to be in a bit of a corner. I'm not allowed to use clientContext and the next best solution being offered is to use DynamicForm.getFocusItem which clearly won't work (and actually can't make any sense if your use of "validate" refers to DynamicForm.validate).

Your help and advice is very much appreciated.

[Isomorphic]

Again, there are many different ways to trigger validation - validation isn't a concept that is even specific to forms, as it happens as part of grid editing and editing in other contexts as well, and of course direct programmatic saves.

So again, relying on knowing which field is being validated isn't even a sensible concept, and the closest thing to this concept would be whichever item has focus.

We don't know why you think knowing the focused item isn't enough, but there is no setting, including requiresServer: true, that can help you with the fundamental problem that it doesn't make sense to think in terms of there always being a specific field that is being validated.

At this point, if you need more help recovering from your use of undocumented internals and correcting this bad assumption, please look at purchasing our commercial services.

[Sophie McHugh]

I find it odd that you think knowing which field is being validated isn't a sensible concept. Can you explain the reasons why?

Also, why would knowing the focused item be enough if there are many ways to trigger validation?

I'm not really seeing the bad assumption you are referring to, it seems more like a poorly designed contract to me.

[Isomorphic]

We've already covered this, but just to be really really clear..

If you programmatically DataSource.addData(), which field is being validated?

If the user makes several changes, navigates away for a while, navigates back and clicks Save, without ever putting focus in a field, which field is being validated?

In both of these cases, and many others, there is no specific field being validated. The whole Record is being validated and it is invalid for validation logic to be based on the concept that a particular field is being validated.