On 14.10.2016 00:13, Erwin van den Bosch via Lazarus wrote:

I'm not a big fan of the RAD development way any more. (I was years ago). The problem is that you should separate your business logic and the GUI.
This is absolutely true especially when doing large systems or (embedded) systems that don't are tightly bundled with the GUI. But even there using RAD for testing/debugging is a way for speed up the development.

And here the addressees are non-computer engineers who most likely will not do large systems on their own, but just should understand what programming means to enable them to talk decently with their colleagues who will do the programming for appropriate projects.

So a fast way ("RAD") to do and test a rather simple working project and understand the basics

With Delphi like RAD it's very difficult to do that. (but it is possible) Everything is coded in events and connected to database aware GUI controls. (In the case of a database application)
I don't think so.

With a more careful design it's absolutely possible to do "non RAD" programs by doing "GUI units" and "business code Units" that interact via Objects with functions, properties and events (callback-properties) .

I believe this is not more effort that using an external GUI designer.

I did this for embedded projects using the GUI units for debugging and testing and then replacing them by dummies without needing to modify the business code units and hence being able to start testing again at any time, while the "GUI-stripped" executable can used on a "headless" target system


Lazarus mailing list

Reply via email to