On Sun, 16 Jan 2011, Graeme Geldenhuys wrote:
On Sun, 2011-01-16 at 07:29 +0100, Martin Schreiber wrote:
The separation of code and user interface definitions has advantages.
Huh? The code describing the UI is just that UI code. My businsess
objects and businesses rules are not located in Form units either. One
of Borlands bad design ideas with RAD - as far as I'm concerned.
Embedded business logic inside form units - something Delphi and Lazarus
IDE's promote.
Graeme probably will encounter the limitations of his approach when he tries
to implement more sophisticated RAD possibilities into fpGUI. Visual form
inheritance and submodules (TFrame) come to mind for example.
I already support the "frame" idea without problems. I can even have
multiple forms in a single unit - something neither Delphi, Lazarus or
MSEide can do.
This is not inherent to using resources, that is simply a design decision.
Keep it simple is a good thing.
What makes resources a good idea is
- Easy Visual Form Inheritance.
- Translation.
- Memory use.
When translating, you typically not only translate strings, but also shift
controls (texts in dutch tend to be longer than their english equivalents).
When using resources, this is done in 1 go, and you overload the original
resource with the new one.
The code to construct the form is always in memory as soon as the binary
is loaded. Resources are left on disk till you explicitly need them.
They can even be in a DLL that is loaded on the go (as done for translations).
You cannot do this with "code constructed" forms.
(maybe it could be done with packages).
All design decisions have their reasons.
Michael.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
