[Lazarus] External/out-of-tree LCL widgetset

[Kostas Michalopoulos]

In my personal experience the "RAD" approach used by Delphi, Lazarus and
old VB (i'm not sure if proper RAD really was about what you see in those
products and not something Borland and Microsoft's marketing departments
decided to use because it was cool at the time) is the fastest and often
best way to create desktop applications. Yes, it can end up messy for
larger applications if you are not careful and i've written my share of
things i'd rather rewrite than fix (although they are fixable with the
right amount of effort), but i still consider it worth it and i see any
other approach as going backwards.

To put it simply, the only reason i use Lazarus and the only reason i
recommend it to others (mainly programmers who want to make desktop
applications) is its "RAD" features (and cross platform support, of
course). Creating a form, dropping a field and a button and double clicking
on the button to type something like "ShowMessage(Edit1.Text);" and press
Run to run it has been for many years my first test for separating Bad vs
Good desktop GUI development environments - and the one most fail at.
Simple things must be simple, complex things must be possible and Lazarus
allows for both.


On Fri, Dec 1, 2017 at 9:43 PM, Graeme Geldenhuys via Lazarus <
lazarus at lists.lazarus-ide.org> wrote:

> On 2017-12-01 13:33, Marcos Douglas B. Santos via Lazarus wrote:
>
>> I believe RAD is the best way to code a GUI....
>>
>
> I'll even disagree with that - somewhat. :)
>
>    http://geldenhuys.co.uk/articles/model-gui-mediator.pdf
>
> With Model-GUI-Mediator (think MVC or MVP design patterns but for modern
> GUI toolkits) you use RAD style to drop components on a form, but you DON'T
> hook into any events or Dataset properties using the form designer. Also,
> you DON'T use data-aware controls.
>
> Instead you use Mediators - a very thin layer of non-gui code (reusable
> and only implemented once) that links widgets and business objects.
> Bi-directional updates occur automatically via the Objserver design
> pattern. MGM was the reason FPC now has Observers built into classes like
> TStringList etc.
>
> The MGM implementation I described in the article is very basic - to get
> the idea across much easier. The MGM implementation inside tiOPF is *much*
> more advanced and improved - requiring *much* less boiler-plate coding too.
>
> MGM also allows you to switch your application from LCL to fpGUI to VCL in
> a blink of an eye. The mediators for all these toolkits are already written
> - so nothing new to implement. Switching a form design from using a
> TListView to TStringGrid (or vice-versa) is also a 2 second job.
>
> Creating mediators for new components....For example TChart ora DevExpress
> QuantumGrid is a 5 minute job at most. So suddenly you can use any of the
> free or paid for components - not just db-aware components.
>
> I've used MGM in multiple commercial projects for about 6 years now - it
> works brilliantly. You UI form units are almost empty, and good separation
> of UI, business rules and persistence. Plus I can use OOP and real
> "objects" in my code, not SQL queries and TField instances.
>
> Regards,
>   Graeme
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
> http://fpgui.sourceforge.net/
>
> My public PGP key:  http://tinyurl.com/graeme-pgp
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171202/e4076e97/attachment-0001.html>