Dynamic Design - A New paradigm in DataEase development

ExecDQLClass(), CreateTable(), AddColumn()* signify a complete breach with previous DataEase thinking.

From its infancy in the early 80ies and throughout its life until DE8 there was a clear divide in DataEase between Design and Runtime. (At least in the head of the designers, but the fact that most people used it interactively and added and changed to it in real time was not taken into account)

Tables, Scripts, Forms, Reports was froozen in runtime and there was few if any way you could make your application dynamic.

How this has changed in 8....

DataEase has always been about evolution. You start with something simple and as you see the need or there is a demand, the feature or function was simply added to the live system. However, there was one sacred boundary - the boundary between what was stored in the application and the application itself. 

This boundary was strengthened from DFD to DFW so there was less a user could impact on the applications behaviour. Throughout the product from DFW 5.x through to 7.1 the designers tried (in the name of security and stability) to close any loophole the developers had in forcing to do anything but "as designed".

The philosophy of the current team is the opposite.

We think that the Developer "own" DataEase not the designers (we). We are simply not smart enough to think of every eventuality or possible usage of the product, so why should we be the ones that decide how it should behave?

DFD was used from anything to keep track of the content of your fridge to run advanced simulation of Oil Reservoirs, taking part in the development of the Space Shuttle, running CashPoints and look after the transport system and traffic lights in entire countries! 

I don't think Mr. Gupta had envisiage that when he made it and when you realise that there was only really 5 different versions (2.52, 4.01, 4.24, 4.53 and 5.14) of DFD it tell you how important it is to get the functionality and the limitations right - and they did (up to 4.53 that is).

It is no big secret that DFW never worked. Not as it should and not as the previous versions of DataEase deserved. It was a failed product!

Yes, a lot of people have used and a lot of people have succeeded in using it but for the majority of DataEase users it never "lifted off".

It was to cumbersome, to awkward, to buggy, to unlikeable -  everything but usable. Especially in the shadow of DFD which was loved!

When we took over DataEase we did't have much if any love for DFW, but we took on an obligation.

By this time we had already produced 7.2 for Sapphire, which was the last of version built according the old paradigm - Stability.

The simple fact that this was the most longed for and asked for "feature" when customers enquired about new versions says it all - failure!

When we came back to take over DataEase, 7.2 was already getting on and it quickly became clear that if we wanted to bridge the old and the new DataEase we needed to do so by "finishing" DataEase for Windows and we started to plan DE8.

One thing was clear from the word "GetGo!" and that was that we would need to change the goal. If it wasn't "stable" enough and "bug fixed" enough after 20 years in development, we wouldn't live long enough to achieve that goal by simply fixing the same bugs over and over again.

Maybe the problem wasn't that it was buggy or not stable enough, maybe the problem was that it didn't "work" and people just looked for explanations?

Personally, I hated working with DFW (and I loved working with DFD). Every time I tried to use it for anything I just got really frustrated and wanted to throw my computer out of the window.

In my now "long" life as a software developer and publisher I have followed one line of thought: "If I understand it and can use it, maybe it will be useful and understandable for one or two more... But, if I don't understand it and won't/can't use it should I assume that someone else will?"

Strangely this thinking has turned out to be rather successful as it seems I am not too different from a normal person.

So maybe I should try to bend DataEase to my ways, rather than try to bend myself to its ways?

Problem is that my way is that I start and then I change my mind 2000 times before I finally finish. I'm not a planner that has everything nailed down before I venture. My rule for travel is to pack a bag (mostly with things I don't need) and then I make sure I bring my passport, my phone and money. This way I have the tools to fix any mistake as I go along.

This was the thinking behind DFD but not DFW. In DFD you simply got started, and then you could fix any mistake as you progressed but in DFW the thinking was swiss army knife or Leatherman rather than Tool Chest. 

You had all the tools you needed on paper, but when you tried to use them you realised that the screwdriver is too short and the wrong size and the pliers basically amputate your finger if you try to apply force - disappointment!

So what about simply forget about the ultimate goal, and simply focus on adding to the tool chest as we found the product wanting?

Maybe it would never be good enough, but this way it had to improve at least?

DataEase has been a product with a lot of "sacred truths". As they didn't seem to help much, we decided to disregard them in 8 and simply plod on as we deemed fit.

The first thing we implemented in DE8 was "Workstation" Printers. It was annoying that you couldn't direct output to printers pr. document  rather than having to select the printer every time you wanted something printed. We are aware that Windows was supposed to be interactive, but that never really worked, and definitely not in DataEase.

With this under our belt we moved forward.

What about Showing/Hiding based on a derivation? Shouldn't that be possible - SetState()

Great. It seems to work!

But so far we hadn't really broken the rules, or crossed the watershed....

What about being able to run a DQL stored in the database, and allow the same DQL to manipulate the look of the Form? That sounds certifiable, so lets do it.

ExecDQL proved to be a game changer. Suddenly you could run a DQL everywhere to do everything. Fast as lightning and stealthy as a B2 bomber if you wanted it to.

ExecDQL grew and today you can basically store the Script and the Layout/Body in your application and run it to generate the sexiest report either to be saved and displayed in a Memo field (webfield), edited further in the HTMLEditor, printed or dynamically generate a PDF.

DataEase for DOS used "itself" much more than DFW ever had. In DFD most system files were DataEase format while in DFW it was all "windows".

One of the biggest problems with DFW is the rigid GUI. Because it is so awkward it has rarely been changed or adapted, so what about using DE85 to make DE85? This way we can constantly improve the use of the product and make it more userfriendly.

It is no secret that "getting started" is the single biggest obstacle for new User, while in DFD that seemed to be as "easy as eating pie...".

In DFW you have always started with a blank pad and a set of crayons, but is that the best way of starting?

Maybe it is better to be able to select a set of elements/features, build an "ARF" - almost ready to fly?

It would be nifty if you could pick standard elements, a nice style and then just have to do the "tailoring" yourself?

So this is what we set out to do.

ExecDQL is one step, but we needed to take over more of the GUI stuff, so the next was CreateTable() - create a table with a form based on an existing "template".

Maybe we want to add some columns to existing tables, so enter AddColumn()*

Install documents used to be such an important part of DFD, but has never really worked in DFW...so fix that! Tick.

So slowly but surely we have transformed DFW from being a stubborn and rigid old "school master" into a flexible and dynamic contemporary...

You might not yet believe it but the proof of the pudding is in the ....

Watch this space.

Published: 06/08/15 - 08:06:44 (Ulrik J Hoegh-Krohn)