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
-Michael
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
