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

[Marcos Douglas B. Santos]

On Fri, Dec 1, 2017 at 5: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.

I am aware of MVC, MVP, MVVM, and now MGM.
I agree with you but, they represent almost the same thing.

> 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.

Unfortunately, it was implemented in a wrong way, using classes
instead of interfaces instances.

> 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.

That is interesting.

> 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.

I think you misunderstand me. I said "RAD is the best way to code a
GUI", the visual part, not the business rules.
I don't use db-aware — well only TDBGrid just to show data — and I
don't have any business rules using TFields, Before|After Post, etc.

Best regards,
Marcos Douglas