It is possible to present information in an orderly way pursuant to criteria applied by developers, based on the contents of the attributes and variables included in the Work With pattern and Work With object node layout or Panel object layout.
In the Conditions selector of the List node there is a place for specifying the Orders in which the information should be listed, and for grouping information according to a specific value (Break By), as well as filters for simple (Search) and advanced searching (Advanced Search) allowed in regards to the data.
There is also a Conditions section that can be used freely and independently from the interface, where conditions may be specified in GeneXus as usual.
For the following examples we have the transaction below, to represent the properties hadled by a real estate:
After we apply the pattern to the transaction, GeneXus offers a default order, search and filter, based on the types of attributes contained in the structure of the Transaction.
If we consider this default information offered by the pattern, we may conclude the following:
- The list will be sorted by property name.
- Searches will be possible inside the fields PropertyName and PropertyAddress, meaning that what the user enters in the Search will be searched within that information:
- There will be possibilities to filter by the attributes PropertyListingDate (in this case offering to select Date From and Date Up To), PropertyOperation (offering the elements of the Operation enumerated, namely: Sale and Rent), and NeighborhoodId, to filter by neighborhood (where something like a selection list will be opened since it is FK):
Each List (or Detail Section) can have zero, one or more orders defined, -making sense more than zero only when displaying information for multiple items-. When there is more than one order specified, a combo on the Smart Device will be displayed at runtime, in order the user selects the one she/he needs. For example, lets suppose we want to offer end user the possibility of sorting the properties list by property name, or by neighborhood name, groping by that attrribute, with property Name being the default option:
To do it, all we must do is add a new Order:
On the Orders label, right click, option “Add/Order”. Give it a name (e.g. Neighborhood). Then, over it, right click and “Add/Attribute”, and select the attribute you need (e.g.: NeighborhoodName). Repeat for each attribute to be added into the order. To remove an Order or an attribute from an Order, the Order has to be selected and right click “Remove” (or Delete key).
Each order specifies the attributes included (and if they are ascending or descending). If an order is marked as BreakBy, this means that the device will make a “control break”, grouping the records that match the value (for instance, to group properties by neighborhood).
The Break by up to order property indicates, when the order is composed by two or more attributes (lets suppose: Att1, Att2, ..., AttN), from first up to what atributte the break will be considered. That is, if we say it is up to Att2, the grouping criteria will be by Att1, Att2. The other attributes(from Att3 to AttN) will be used only for order proposes inside each group (and not for grouping itself).
Allows a control break in the List without caring the order listed.
The attributes defined in the Search node will be displayed at runtime as a string to make text searches in the entity’s fields. The instance specifies the fields on which the search has to be performed. Having the default WorkWithDevicesProperty Conditions shown above, the search fields will be PropertyName and PropertyAddress. The implementation is an OR, that is to say, it returns any record that has that string in a field.
The criteria used for the default attributes added by GeneXus to the search are as follows:
1) It isn’t a “foreign” attribute (that is, FK, or inferred by FK).
2) It isn’t based on an enumerated domain.
3) It is of character data type or variations (varchar, longvarchar)
4) It doesn’t belong to any of the following domains: Audio, Component, Feed, Geolocation, Phone, Video.
5) Therefore, the following predefined domains are included in the search: Address, Email, Html, Url
The ones not included by default, except for the Audio and Video domains, can be added to the Search.
All characters can be used to make a search.
Among the Search level properties, there are:
Filter Operator: with "Begins with" and "Contains" values (being "Contains" the default)
Case Sensitive: with "True" or "False" values (being "False" the default). This property is taken into account when the DBMS is insensitive. That is, if the DBMS is sensitive, the property is not taken into account for setting that is dominated by the DBMS. A DBMS level can be set on many levels, default level DBMS, BD level, Table level and column level.
Option For Individual Fields: with "True" or "False" values (being "False" the default). Setting "True" (for iOS only) you can specify if the user can (also) restrict this search to one of the search fields. For example:
Having "False", if the user enters the "D" letter, the search is done by Name or Address (assume the Green Tree property address contains "Dixie" word, so "D" letter). Whereas having "True", he/she has the possibility to search by all fiedls, or to choose searching by one of fhem (Name or Address).
They are the Work With (Web) filters. Certain data is requested on screen (such as “advanced filters”), with a possible default value. All the filters that have an entered value take part in the query, and an AND is applied among all filters. The filters that don’t have entered values (or the value is “All” when combos are involved) are not applied.
Depending on the data type, the kind of data entry offered to user in order to filter:
- Value: A value is requested and filtered with that attribute and value (there is an implied condition according to the data type).
- Range: Two values are requested, and the attribute must be in that range (e.g.: the Listing Date filter above). If only one of the values in the range is entered (minimum or maximum), the records selected are those with the greater than or equal to condition, or lower than or equal to the entered value. The default instance adds this type of filters for all the attributes of date type.
- Combo: A value is selected from a fixed list, usually given by an enumerated domain (e.g.: the Operation filter above). The search returns all the records that meet the condition of greater than or equal to the entered value. If only the records that meet the equality condition are to be obtained, the Custom Condition property has to be configured with this value: <attribute>=<variable> when not <variable>.IsEmpty(). The default instance includes this type of filters for all the attributes based on an enumerated domain.
- Dynamic Combo: A value is selected from a dynamic list (given by another attribute). In GeneXus, they are dynamic combos (or prompts). The default instance includes this type of filters for all the attributes which are foreign keys (e.g.: the Id filter above, by the NeighborhoodId attribute).
In addition, it is possible to add new filters with the Add button... or remove them using the Remove button.
It also allows to specify free conditions, in the bottom-most screen (in the same way conditons screen of a web panel does). For example, If we just want to always (not giving user the chance) obtain listings of the properties on sale, we can specify a Condition, just as we would do in any Web Panel object or Work Panel object.
In the image compositions below, we have the “before” and the “after”.
The Detail node is more limited because the information shown is usually not repeated, except in the case of subordinate Sections of the table of the Work With pattern and Work With object.
For example, note for Section(Property) (that lists into a grid all the properties belonging to the neighborhood selected) there are not default conditions (beyond the implicit one, given by the rule: "parm( NeighborhoodId)"):
The user could add orders, search attributes and filters, as well as conditions, in the exactly way explained above for the List node. The same could be said about the Panel object.
You can see this examples on RealEstate.
Work With for Smart Devices – Orders, Searches and Filters