Table of contents

Introduction

Development Environment

Web Development and Improvements in user experience

(Productivity and Enterprise-level Application Development Features)

Ajax Overview, [[21759|GeneXus' target='_blank'>Ajax' target='_blank'>Ajax Overview, [[21759|GeneXus and Ajax]]

Business Components

Business Component - Publication as an Enterprise Java Bean

Practical course: Bluesky Charters
 

Application Localization

Application Localization
Demo
Translation Tool
Help "in any language"
Practical course: Bluesky Charters
 

Patterns

About this topic
Patterns based development
Description
Built in Patterns
Work With Pattern
Demo: Work With Pattern
Practical course: Patterns
 

Better data model

Null handling optimizes navigations
Nulls property

 

User experience

New options on rightclick in win
 

Reverse Engineering

Database Reverse Engineering Tool
 

New Platforms

MySQL
.Net Mobile Generator
More J2EE support than ever
 

Data Types and Methods

Message Queue handling data types

DirectoryDataType
LDAP Data Type

URL access Property
New IIF function
New byte count function
New Methods for attributes, variables and enumerated domains!
XSLTApply Method
Procedures can now call web objects
Web Services: Grouping Locations
News about model, object, and control properties


Unofficial Content
  • This documentation is valid for:

GeneXus 9.0 Upgrade Course

Given a transaction level, the only attributes that can be editable are the ones stored in the BaseTable of the level. For example in an Invoice transaction, you can have the CustomerName in the form, but it isn't editable, the only attribute of the Customer that can be edited in the Invoice form is the CustomerId because its stored in the Invoice table.

The new rule Update() is introduced for the case the developer needs to edit the CustomerName anyway in the Invoice form. This example seems to be a not very common one, but there is one case where this rule is more applicable: in the form of a subtype of another transaction. For example if you have Party and Client, where Client is a subtype of Party, and ClientName is a subtype of PartyName , you want to change the ClientName directly in the Client form. In this case the rule Update(ClientName); will do the trick.

Description

The Update rule allows editing/updating attributes that are not stored in any of the base tables of a transaction.

The syntax is as follows:

Update( att1, ..., atti );

where:
att1, ..., atti: attributes belonging to the extended table.

This rule is unconditional. Therefore, to conditionally allow editing of a particular attribute you should combine it with the Noaccept() rule.
 

Example

Party Transaction
Party*
PartyName

Customer Transaction
Customer* subtype of Customer.Party
CustomerName subtype of Customer.PartyName

Rules: Update( CustomerName);

The above example shows how to make the CustomerName editable in the Customer transaction even this attribute isn't stored in the Customer table (in fact it's an inferred one, and its supertype PartyName is store in the Party table). The expected behavior is that CustomerName attribute is editable in the Customer transaction.

The Navigation report shows tables that are updated through this rule.

Considerations

  • Transactions may have either one or more Update rules. There is no preferred method for writing them.
  • No errors or warnings are raised for this rule (i.e. reference to attributes that can already be accepted).
  • Some considerations about the rule behavior in update mode:

If the foreign key determining the inferred attribute can be changed (i.e. it does not belong to the primary key of the base table) and it is changed in different transactions (units of work) then, the value of the inferred attribute for the "original" foreign key value is _not_ restored. An example may clarify the concept:

Suppose we have two Transactions: Customer and Invoice related. CustomerCod is a FK in the Invoice and it has the rule: Update(CustomerName)

It has an Invoice #1 with CustomerCod = 1 whose CustomerName = "Customer_x".
The CustomerName value is changed (in fact the CustomerName is updated in Customers Table) in the Invoice #1 to "Customer_new" and the Invoice is confirmed.

After that (in a new LWU) the CustomerCod for invoice #1 is changed to another value, for example, CustomerCod = 2. This change doesn't means the Customer #1 Name is restored to its original value.

Scope

Objects: Transactions
Languages: All
Interfaces: Web, Win

Last update: November 2024 | © GeneXus. All rights reserved. GeneXus Powered by Globant