Op 2011-01-17 12:03, [email protected] het geskryf: > I have an application with 1500 forms. It would be madness to have to set > over and over again the same set of properties and event handlers to > save/restore formlayout, ask to save unsaved data, sort grids and > whatnot. So [...snip...] > > After that, you create new forms extremely fast without losing RAD > functionality: a pure point-and-click environment, which is always > faster than coding, and which is understood by people of many skill levels.
And our company does exactly that, but without the need of a specific IDE's RAD functionality. Every heard of code templates? ;-) I'm a self-confessed code templates junkie! There, I said it! :) I can slap together stax of usable forms or code, with functionality like mediators, auto save/restore form positioning, localization etc all enabled, simply by using a few of our designed code templates - and a lot faster than anybody can drop components on a form & double clicking to set event handlers etc. Clearly each development team has their own way of working. There is no right or wrong. I'm simply stating that "RAD" can mean many things to many development teams. And the "RAD" Borland was marketing, by writing a crap load of business logic inside form units, is NOT the way our company works. I learnt my lesson at a previous employer, after having to help maintain a *huge* Delphi "RAD based" project. See my favourite URL of that "brilliant Borland RAD idea" in action. http://opensoft.homeip.net:8080/~graemeg/datamodule.png Just looking at it, makes my eyes tear. :) > Since it is simply OOP, You could do all of this in code, but code is > slower to create and is more error-prone. Why error-prone? If you use well tested and developed code templates, you end up with having consistent looking and tested code. eg: Taking the tiOPF's MGM functionality as an example: We use StringGrid's a lot in our products, but all the developer needs to do is drop a grid on a form. No need for tweaking the grid's property settings etc. Then simply create an instance of our StringGrid mediator, and the grid is done. Instantly that grid gets all our preferred settings and event handlers setup, plus customized painting etc... all my hooking up one mediator to a stock standard grid component. Now if we wanted to update the look of all our grids in our project, we simply have to modify our base stringgrid mediator class, and recompile our project. Quick, easy and consistent! > Hence RAD and point-and-click. Which could result in one form's Grid not quite behaving like the other form's grid in the same application - because the developer forgot to set all the right properties for the 100th time. So RAD can have many meanings and implementations, depending on the team. The mouse-style developer is not the begin-all, end-all of software development. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
