I wrote this article before I knew about Delphi's "data module" things, which are placeholders for components. However, the data modules in delphi are still limiting and require kludges to get them working with applications, such as inheriting from the correct class in order to make them work. MseIde/MseGui is better with regards to data containers or data modules by the way.
The "data module" in delphi was also seemingly intended for data related components, whereas I think general application components of all sorts could be placed onto an application container.
What a data module was designed for: See this About.com Delphi Article
Regarding Lazarus, Delphi, and IDE's who base the entire application around forms.
Some developers need to build daemons, server software, CGI programs, non-GUI programs - not just GUI client software. When it comes to building server software in an IDE based around forms, there is no way to utilize the IDE components anymore since nearly all of them are based around GUI forms. But some applications are not GUIs. People just open up the IDE's text editor and start coding away plain text when doing non gui coding. But is this the most efficient method of coding?
What if you wish to organize code visually, without using Forms? It would be nice to drop something on the screen to inspect what it does without having to look through the entire unit's source code, in some cases (when we don't have time or good documentation). Classes alone won't do that for you, nor will units or interfaces. Those don't offer any visual method of dropping a component on the screen and inspecting it's properties.
The solution to this problem would be invisible (at run time) container forms. The containers would be visible at design time, holding components primarily for organization of non-form related run time code. Think Indy and Synapse (internet components). Why does indy go on a form? It has nothing to do with GUI, and nothing to do with a form. Why not put Indy component on a container that is invisible at run time? Indy has nothing to do with Form1 or Form2. Indy should be dropped into your application container.
A container form, or a container window, or container box can be displayed on the screen during design time, but it is not actually compiled into the application as a GUI component.
Containers on the screen would allow a developer to drop components on the screen in an organized area, and set some properties for components at design time with the object inspector, without intruding into the other GUI forms. Delphi doesn't do this: you drop all the components on Form1 and Form2 no matter what. And if there is no form in your project (non gui program), then you're stuck, since the IDE is so form based.
Imagine you have an internet component that you want to drop on a container. This container just organizes your components for you. The internet component is not visual GUI form related, it just holds some components related to the server logic or the program logic. So it should not be placed on a visual part of your application like a Form, it should instead be placed in a separate "application container". The application container would be like "application1 form". Instead of a GUI form, it would be an application form.. hence not really a form at all.. just a container holding components.
This brings up another problem with form based IDE's. They allow you to drop components on the form that don't serve any visual purpose. But why drop them on the form at all then? Drop them into a container, so they don't disturb the other components on the form. Many times in an environment like Delphi or Lazarus, a non visual component will get in the way and will be hard to click on or find if there are visual components covering it. The solution is a separate container window or container form who serves no runtime visual purpose. Just purely a design time visual purpose.
For the non-visual source code units, it can be advantageous to have some sort of visual organization system in addition to just the unit source text. If you could for example, drop an Indy or Synapse component onto a container, not a form, for purely design time purposes.. and muck around with the settings at design time - this would be better than if the component was on a Form. Because not all Synapse or Indy applications involve GUI forms! Dropping the unit onto a form and then hiding or disabling a form is not the answer. That's fixing a problem with a broken solution.
The problem with non-visual development is lack of visual organization. That doesn't automatically mean that everything must be visually dropped onto a GUI form! No, we should be able to visually organize code using non-gui forms.. i.e. containers, place holders. It's hard to understand what I'm talking about if you come from a Delphi background and you only know what forms are. What I'm describing here is a new invention and it doesn't exist yet.
The solution is containers and component holders who are visual at design time only.
It is of best interest, for open projects like Lazarus, competitors to delphi, similar projects to delphi, etc. to not follow Delphi verbatim. It is instead wise to innovate and engineer the IDE better than what we already have. We already have form based and form centric development, which doesn't work well for serious applications. All serious applications should involve both containers and forms, not just forms. Forms cause people to shove everything on forms, when not everything is meant to be on a friggin' form.
Just because Delphi had a good idea, doesn't mean it's the best idea. It's great for GUI development - but the core software and code that talks to or communicates with the GUI is not always GUI centric. There is room for innovation.
|
