GeneXus 9.0 Upgrade Course
Web applications have many advantages over Windows or green screen applications but -until now- they also had some drawbacks. The most common one is that they aren't as interactive as Windows applications. As from GeneXus 9.0, Web applications are as interactive as Java or .NET Windows applications thanks to Ajax .
This feature adds great value to GeneXus-generated Web applications. Because doing the same thing by hand is very cumbersome, it is not usually found in real applications.
The purpose of this feature is to increase the interactivity level of Web Form applications using Ajax architecture. This is the new behavior of Web applications, making them more attractive at no development cost.
As the end user moves among screen fields and/or enters data in them, the data will be validated, the extended table attributes will be inferred, and the defined rules and formulas will be triggered. All these operations will be interactively executed so as to allow the end user to view the results inmediatly. Anyway, full screen dialog features will remain. When the end user confirms the data, full screen data will be saved after triggering all validations, rules and formulas.
As we'll see, the behavior is exactly the same than .NET or Java Windows applications with the Client Side Validation property set as Yes. There are, however, some few differences, inherented to Web, that we'll mention below.
Web Client Side Validation does not replace the server-side code in any way. This means that data is revalidated and formulas are reevaluated on the server before updating the Database.
GeneXus generates code that runs on the end-user's browser for the rules and formulas that you write in your Transactions. In this way, early feedback (no need to submit a request to the server) is provided to the user. The generated code language is JavaScript , so the Browser must be JavaScript-enabled. Some rules, for example those requiring Database access, access the server to return results in real time. Thanks to Ajax, it's not necessary to reset the whole page in the Server to send it to the client. That's why this is a viable solution.
When loading the requested page in the browser, the javascript code will also be sent to:
- Trigger rules that don't depend on any trigger events. That is to say, rules that depend on the natural evaluation tree.
- Trigger related formulas, according to the evaluation tree.
- Perform referential integrity checks and infer the corresponding data.
- Validate attribute data types
The same behavior as in Windows applications is expected regarding the triggering of rules and formulas as the user enters data in form controls. For instance, when the user leaves a control, the focus shifts to the following accept control, triggering all rules and formulas that depend on the control that has just been left, and on any no accepted controls that may appear.
For example, suppose that fields A, B and C appear in the form, in that order, and that field B is noaccept (because it is inferred from A). When the user leaves field A, the focus will be set on field C and all rules and formulas associated with attributes A and B will have been triggered.
If an error occurs, the focus is enabled in the first control that throws the error.
The place where messages are displayed depends on the triggering time.
When a message or error is triggered in the server (such as a duplicated record), it will be displayed as a list in the ErrorViewer control.
In addition, a text box control (client side error viewer) will now be displayed on the control that triggers a message or error when leaving it.
These text boxes will act as windows displayed in a .NET or Java application with CSV set to yes, when showing a message to the user in relation to data entered in the control that he/she has just left.
They have two classes associated with Themes: ErrorMessages and WarningMessages that belong to the Messages class.
It's worth mentioning that the Error Viewer will continue to display all messages or errors that don't depend on the form control that the user has just left. For instance, stand-alone rules will be displayed there. Likewise, when the user sends the page to the server, all rules and formulas will be retriggered. All messages that were triggered in the client and are still valid will be redisplayed either in the text box or the Error Viewer. Besides, rules associated with trigger events (AfterValidate, AfterInsert, etc.) will be executed for the first time, which may generate messages and errors that will be displayed in the ErrorViewer.
The behavior is exactly the same than .NET or Java Windows applications with the Client Side Validation property set to Yes. There are, however, some few differences, inherented to Web, that we'll mention below.
- In Windows applications, there is a property to set this behavior (The Client Side Validation Property at model and object level). The Web applications always have client side validation.
- The transaction´s mode is inferred in Win applications, so the Get button is not present in the form. In Web applications the mode is not inferred so the Get button is, by default, present in the form.
- In web applications the transaction "Confirm" (Apply Changes) button doesn´t change the text depending on the mode.
- In web applications you can´t manage a logical work unit that involves more than one transaction. In Win applications this is possible.
- The message that displays the result of an insert, update or delete action is shown in the status bar. In Web applications we use the Error Viewer control.
1) We will explain now some considerations about the rules and formulas triggered in the client side moment using an Invoice transaction sample (with Customers in the first level as a Foreign Key and Products in the second level as a Foreign Key). All this does not ocurr in the server side validation.
- Conditional noaccept rule over read only attributes (e.g. foreign keys) is not suppported.
- The Product Stock is not updated when adding the same product in different lines; in that case it always takes the original Product Stock. This also happens in Windows applications.
- The Product Stock is not updated correctly when changing the product in the same line. This also happens in Windows applications.
- If a Product Code is 0 in the invoice lines, the Product is not validated. This behavior is the same in Windows applications; for example, if you don't change a field in a line, that line is not validated.
2) The server entry points related to Ajax validation are being called using clear text even if the object property 'Encrypt URL parameters' is set to Yes.
Let's see how the well-known Invoice sample works in GeneXus 9.0 for Web.
The Invoice transaction is as follows:
InvoiceID*
InvoiceDate
CustomerID
CustomerName
CustomerAddress
( InvoiceLineID*
ProductID
ProductName
ProductStock
ProductPrice
InvoiceLineQty
InvoiceLineAmount)
InvoiceSubtotal
InvoiceTaxes
InvoiceTotal
We have also created Customer and Product Transactions. Thus, in the Invoice Transaction, CustomerID and ProductID are foreign keys that infer attributes such as CustomerName, CustomerAddress and ProductName, ProductStock, ProductPrice.
To create a friendly application, we set the CustomerID and ProductID InputType Properties (we'll see them shortly) with "Description" value, so it is not necessary to enter codes. Besides, to avoid remembering exact names we set the Suggest Property with "Incremental" value.
The formulas defined in the transaction are as follows:
InvoiceLineAmount = ProductPrice x InvoiceLineQty
InvoiceSubTotal = SUM(InvoiceLineAmount)
InvoiceTaxes = InvoiceSubtotal x 0.23
InvoiceTotal = InvoiceSubtotal InvoiceTaxes
When a user opens the application to add a new invoice and presses the Tab key over the CustomerName control, a "No matching Customer" message is displayed.
After the customer's name is selected from the combo, the CustomerAddress is automatically displayed as in Windows applications.
In the same way, after selecting the Product Name, the Stock and Price attributes appear on the form.
When the user types the corresponding quantity, all the formulas that depend on this attribute are calculated.
To implement this client-side code, GeneXus generates Java Script code.
For Web Transactions, a tx.js file is generated with the client-side part (all the validations of the transaction).
These files are located with all the other .js files of the model.
The text box control (client-side error viewer) is implemented with a file named gxballon.js that displays client-side messages.
Languages: Java, .NET
Interface: Web
Official 'GeneXus and Ajax' site
Sample to see ajax features running online
Sample KB to download
More information about Ajax