Skip to content

Application Interfaces - Desktop vs. Drilldown

View Navigation Options
Summary

The drilldown interface has some significant differences from the desktop interface. Desktop style views rely much more heavily on finding keys and their corresponding prompt lists. The desktop style does not distinguish between data entry mode and query mode. For example, when a DEO is associated with an index, record finding can be used to query data or to enter new data. The end user makes this choice. The desktop style encourages the use of Zoom to Select as its query model (e.g., a view invokes prompt lists). It is also a flat system where you never query more than one level. This flat system makes it very easy and efficient to switch between views. All of this works very well when operating in a traditional “windows style” that has a large screen, a fully laid out keyboard, and an accurate pointing device. The desktop style is designed to allow the end user to determine the application flow.

The drilldown interface is a better choice for mobile/touch devices, where you have limited screen space, a less precise pointing device (your finger), and a limited keyboard. In this environment, it is best if the application flow is pre-defined by the developer. A drilldown style is better suited for this. The style turns the desktop style around. You tend to start with lists (Select views) and then drill into your data until you find what you want, which is often displayed as forms (Zoom views). This is more of a Select to Zoom model. This is not a flat system, and you will often be running a query many levels deep.

Because of the differences between the Desktop and Drilldown style applications, the behavior of the DEO objects within the two styles of views needs to change. This includes:

  1. In Select to Zoom models, you don't want to allow finding on main file DEO table columns. That finding has already been performed by the Select view. Therefore, prompt buttons never appear on main file DEOs.

  2. If you have a Zoom view that has parent constraints (e.g., Customer Select -> Orders Select -> Order Zoom), you may need to support parent lookups for some DEOs (e.g., sales person), but not others (e.g., Customer). However, if the query here started with Sales Persons, these restrictions should be reversed. If the query started at the Order level, both restrictions should be lifted. If the same view is going to be used for multiple purposes, the DEOs need to know how to handle this on a dynamic basis.

  3. In the drilldown style, classic DD based prompt lists are not used, as they are too inflexible for this style. These are replaced with Select views that can be for both prompt list-like selections (close and update) and forward navigating queries. In some cases, you need to use both of these at the same time. Because of this, the developer needs to explicitly set prompt buttons in forms and code the forward navigation.

  4. Autofind should never be applied to main file DEOs. However, an “error if autofound” might need to be applied when assigning key field values to new records. If the key already exists, an error should be immediately raised.

  5. Existing key field DEOs should almost always be disabled. The concept of “noput” (allow data entry for finding but never actually save these values) doesn’t arise with this style.

  6. Creating read-only views makes a lot more sense. With the standard desktop style, making all DEOs read-only (disabled) also disables the ability to find records, essentially disabling queries. With the drilldown style, these queries are part of the drilldown process and the Zoom view is the last thing you see. Keeping this Zoom view read-only (unless you really need to edit) has the advantage on mobile/touch in that it keeps the on-screen keyboard out of the way.

There are other examples, but this shows that the drilldown style must have a different set of rules for enabling DEOs and that the enabling and disabling of these DEOs need to be more dynamic. Rather than requiring that the developer find and make all of these changes, the web framework DEO logic has been extended to support most of these automatically.

DD Defined Prompt Lists and DEOs

The desktop style of DataFlex applications in Windows and Web uses standard prompt lists to lookup data. These are assigned to table columns in your data dictionaries and they appear automatically when a DEO is bound to that table and column (using the Entry_Item command). For a number of reasons, this model is not used in the drilldown style. In the drilldown style, prompt lists are too single-purpose, you would not use them for main file lookups, and they are modal. When a cWebView is being used drilldown style, the DDO’s web prompt object is ignored. Instead, Select views are used to replace the functionality of prompt lists. The Select to Zoom model replaces the need for main file prompts. When parent lookups are required, they can be handled with Select views.

The main place where the traditional DEO prompt process would be used is to find a parent record in a Zoom view, where you would invoke a parent Select view for selection purposes. When you need to do this, you need to set the DEO’s pbPromptButton property to true and specify the navigation inside of the OnPrompt event.

Object oCustomerCustomer_Number is a cWebForm
    Entry_Item Customer.Customer_Number
    Set psLabel to "Customer"
    Set pbPromptButton to True
    Set peLabelPosition to lpTop

    Procedure OnPrompt
        Send NavigateForward to oSelectCustomer Self
    End_Procedure
End_Object

The desired navigate from-type is nfFromChild (i.e., it is from a child view that needs to select a parent). The invoking object (the Self parameter) should be a DEO bound to a parent table and the view being invoked should use that table as its main DDO. Typically, this will navigate from a Zoom view to a Select view where the Select view will provide the functionality of a prompt list. The Select view has the full capability of any Select view so it can also be used to navigate forward to view more record detail, add a new record, delete a record, etc. From the framework’s point of view, the OnPrompt event is just another event that can be used to perform navigation.

Even when pbPromptButton is set to true, it may not be available. When a DEO is disabled, the prompt button will not be shown. Also, if the parent DDO that is being prompted is constrained because of the drilldown path, the prompt button will not appear. Consider a query that may be Customer Select -> Orders Select -> New Order Zoom. In this case, the Order Select view and the New Order view must already have the selected customer as its relates-to constrained parent and this parent cannot be changed. The framework will automatically set these constraints for you. Assume that the prompt button has been enabled for both Customer and Sales Person. In such a case, the framework will automatically disable a prompt button for a customer prompt, while allowing the Sales Person prompt. If the same view was queried from a different context, Sales Person Select -> Orders Select -> New Order, the customer prompt would be allowed and the sales person prompt would not appear. If the query context was Orders Select -> New Order, both prompts would be allowed.

Previous Topic: View Navigation Options
Next Topic: Summary

See Also

Developing Web Applications