DO & DON'T : Datawindow expressions

[Former Member]

As PowerBuilder consultant you have certainly used and abused of the DW expression, usually to show/hide, set font properties or colorize DW objects.

But again, there are bad and good way to use them :

DO : Use DW expression only for the simplest cases

Remember that in contrast of its powerfulness, the expression dialog to be used is still as spartiate as it can be !

• no syntax highlighting
• no resizable dialog
• no formating available

At the end, even with almost 20 years of practice, it is still difficult to read them afterward.

So keep it as simple as it can be.

DON'T : Mix DW expression and PowerScript code to handle the same DW object

This is one of the biggest and easiest mistake you can make in PowerBuilder.

Not only you will induce in error the one that will come after you sometime later, thinking instinctively that it is the DW expression that manage the behavior of a particular DW object, then being totally surprised than the behavior stated is not the expected one, when running the application !

But also you are complexing the maintenance by having to synchronize multiple code locations, and with the time, desynchronization of the code and the dw expression will come irremediably.

DO : On new project, choose one paradigme and stuck on It.

When starting a new project, it is the good time to choose one paradigme, either using DW expression only or PowerScript only do dynamically change Dw objects properties according to the context of use. Once a technique is used, stuck on it until the end of the project.

My advice, will depend on how the developer team is staffed.

If it has only pure PB developers, use DW expressions without hesitation but using particular techniques to produce more concise and readable DW expressions.

Otherwise, use PowerScript inside dedicated NVO or Business Objects (bo).

DO : Use the TAG property to document what Business Object
         is managing what DWO

The difficulty when using PowerScript to manage the dwo property will be to exactly know what BO is managing what DW object.

One tip will be to use the TAG property of any managed DWO to designate somehow what BO is managing this particular DWO.

For example, [BO:n_cst_MyBo::of_Setxxxx] tell you what NVO is used and in what function the actual dwo is managed.

Nice and easy to maintain !

DO : Use Global Function to simplify expression

This technique is a good compromise where it is clear that it is in the DW that the logic start from, but it also simplify expression by calling  well named Global Function. In turn, these GF could also call BO functionalities.

That way, you can encapsulate all the complexity inside Bo's while keeping Dw expression as simple it can be plus producing self documenting code.

DO : Use Computed Column to simplify DW expression

Using computed column inside you data source SQL, will allow you to simplify the DW expression by using its name instead of doing all the logical stuffs directly in the DW expression.

DO : Use invisible Computed Field to simplify expression

If it is not possible to use Computed Column nor Global Function, use invisible Computed Fields to simplify the main DW expression.

Be aware, that this technique may lead to unexpected results if using computed field depending on result of other computed fields.

The reason is that we can't know in what order the computed field expression will be handled by the datawindow engine.

Thus better use static data (column, computed column) inside these computed fields.