[Lazarus] fpGUI

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Mon Jan 17 17:28:32 CET 2011



On Mon, 17 Jan 2011, Marcos Douglas wrote:
2011/1/17  <michael.vancanneyt at wisa.be>:
>> I don't have to. But 80% of the functionality returns.
> This 80% is taken care of. The rest is business logic.
>
> Business logic in the Form class?

We work 3 tier. 
Most important business logic is on the application server. 
Clients contain mostly presentation logic.

>> That's it. 95% of all forms descend from TDBappform. The rest descends from
>> TAppForm.
>
> Never happen to you have a child form (inherited of TDBAppForm) but
> with special features such that it did not fit well with the routines
> of TDBAppForm? So what did you do? Maybe you skipped some TDBAppForm's
> methods having to implement them again, otherwise, only for this
> particular Form, no?

No. The 'extra' functionality is just never used in such a case.
(in 3000 forms, there are 2 such cases)

And remember: I do not try to foresee all possible situations.

I try to make sure that 99% of all cases are covered. 
The remaining 1%, the programmer is free to use his imagination.

>> That depends on your definition of big.
>>
>> The form class together with all it's 8 auxiliary classes takes 2300 lines.
>> I don't think this is big.
>
> Well... 2300 is not so big.
>
>> And you make a common mistake: you try to do everything in OOP in the parent
>> class.
>
> Just when I use OOP.
> I have Forms RAD and Forms OOP (but just in Delphi... in FPC, I'm a
> newbie for now).
>
>> What is more, if now we need a new functionality in all our forms,
>> I introduce it in the form class, and all our forms now automagically have
>> this functionality. This has happened numerous times in our application.
>>
>> If your application has only 20 forms, all this is not worth it.
>>
>> But when I started, I knew that there would be lots of forms, and an
>> application that would evolve over 10 years.
>> I did as I described here, and this has saved us huge amounts of time. The
>> whole team and management here agree on that.
>> (one of the few things management and developers agree on ;-) )
>
> I believe, sure. But my point is that can be done with code/classes
> without RAD approach too.

I know that, I do not dispute this.

I just want to point out that RAD does not mean one has to make compromises.
It is a good concept, which really allows to work fast.

Michael.




More information about the Lazarus mailing list