Request_Clear - cWebBaseDEOServer

Performs a DD Clear operation

Type: Procedure

Parameters: None

Procedure Request_Clear 

Call: Send Request_Clear


Request_Clear performs a clear operation by sending Clear to the object's DataDictionary object (DDO) Server. If clearing may cause data-loss, a data loss verification message may be sent. This message is only sent if the DDO is changed and the data entry object's (DEO's) Verify_Data_Loss_msg is set. This operation is performed using the RequestClearExec message as described below.

Note that this performs a DD clear operation. Clears propagate up the DDO structure, clearing parents until a relates to constraint is found between a DDO and its parent.

Delegation of Request_Clear messages

Data entry objects (DEOs) may explicitly set their DataDictionary object (DDO) Server by placing a 'Set Server' line directly within the object. More often, DEO objects set their server implicitly by acquiring its server from an ancestor object via delegation. This way, a group of DEOs can all share the same server. This is the recommended approach. When a server is not explicitly set, the Request_Clear message is delegated to the parent. This process is repeated until the DEO with the explicit server is found. Often this will be the view (cWebView or cWebModalDialog) object itself. This means that all similar Request_Clear operations are handled by a single method in the view, making augmentation simpler.

RequestClearExec - Request messages and user verifications with web objects

When the browser client selects a save, delete, clear or clear-all, the message Request_Save, Request_Delete, Request_Clear or Request_Clear_All is sent to the server. These do a traditional DataFlex style request operation which is validation, verification and then the actual DD operation (Request_Save, Request_Delete, Clear, Clear_All). A verification is required based on the contents of Verify_Save_msg, Verify_Delete_msg and Verify_Data_Loss_msg. If a verification is required, the client needs to get involved to perform the user verification. This means that the operation requires an additional round trip. If the verification is accepted by the user, a message is sent to the server which handles part two of the request. Those part two messages are RequestSaveExec, RequestDeleteExec, RequestClearExec and RequestClearAllExec. These are the messages that attempt to actually perform the requested DD operation. You can think of these as "pre" and "post" messages.

If the verify messages are 0, which means that a user confirmation is not needed, the "pre" message (e.g. Request_Clear) will directly send the "post" message (e.g. RequestClearExec) without requiring an additional trip to the client.

Here is an rough outline of what happens with a Request_Clear (after the delegation to the DEO that sets the explicit server).

    If no changes return
    If Verify_Data_Loss_msg exists, tell the client to present the verification and make a callback *
    Else Send RequestClearExec

    Send Clear to the DDO

* If the user confirms the operation, the client will make another server request which will indirectly send RequestClearExec.

If you need to make a save, delete, clear, clear_all request manually (e.g., within a cWebButton) you should use Request_Save, Request_Delete, Request_Clear and Request_Clear_All and not these "exec" messages.

If you are augmenting these requests, you need to be careful as they occur in two steps and it is possible that the second step (the exec) may not get called at all. Notice that the "pre" message (e.g., Request_Clear) may have actually performed the entire operation (if there is no verify message) or may have merely launched the operation which might be completed during the next server "post" request (e.g. RequestClearExec).