In html design, a developer doesn't have to use pixels.. he can use percentages and 'ems' measurement. You can do pixel development with CSS too, but it isn't always portable to different screen resolutions.
So I was even thinking that to start with... one could drop HTML TCheckboxes, Textareas, Radio buttons in the container form (i.e. like a TDataModule) rather than a pixel form. To start with though.. not that I'm saying you couldn't add pixel development later.
Sure, when one figures out how to hook up delphi/lazarus forms to pixels it will be nice.. but we can also make a compromise in the mean time and get something working using containers/tdatamodules to start with.
If one tries to develop a full fledged pixel system, he may end up with an incomplete project like TurboPHP and Qadram. Those tools kind of work.. but kind of don't.
So pretend we have designed a container form that can hold things like Indy components and TCheckboxes and TButtons.
procedure DisplayWidgets;
begin
DataModule1.Checkbox1.show;
DataModule1.Radiobutton1.show;
DataModule1.Button1.show;
DataModule1.Edit1.length:= 40;
DataModule1.Edit1.show;
end;
procedure ProgramLogic;
begin
// code..
// code..
// logic..
// logic..
// code...
// eventually the logic has to instantiate the display
DisplayWidgets;
end;
That gives a lot of power and control over how the widgets are displayed.. compared to static HTML files using WebTemplateOut.
This would be a reinvention of Rapid HTML and htmw units. However, the rapid HTML units don't work with TDataModule visually. Rapid html widgets are also not using 100 percent classes. They use records and objects.
The benefit of these TDataModule things or container things would be that it would attract more Delphi developres who must use visual development, even if not pixel development. Many Delphi developers love 'forms' of any sort, even if they are fake container forms that don't actually work as pixel forms. They love 'any sort of visual development' and it would allow quick prototyping of programs using the mouse to drop components on forms.
We also have to consider that things like websnap/webbroker/intraweb don't seem to be liked by some folks.. so we must keep this in mind too.. not to make things too complex.
Complexity and Websnap Brainstorming
I think inevitably we make things more complex as soon as we add more Create/Free syntax inside the code. I mean the only difference between Powtils and WebSnap is that with Powtils we don't require Create/Free noise in the code all the time. Honestly, its due to using the stack more often and due to having some procedures and functions available instead of always putting methods in classes.
If you think about it, this is really the only difference. That and our initialization/finalization in the pwumain unit which initialize the http headers automatically, instead of it being inside a class constructure method. And also our built in security and basically just the fact that we have more functions available in units than websnap methods in their classes. It's just different ways of doing data hiding/encapsulation.
Pixels
Or, you could try and do something like Qadram/TurboPHP with the pixel forms to start off with..but I think that is a huge undertaking. Rather, why not start of incrementally by doing the easiest thing first.. a visual container without any worries of pixels. The problem with huge undertakings is that sometimes they end up failing or being abandoned, like turbophp.
My point is: first one *could* start off with reasonable goals and expectations and develop components that you can drop on a container first, rather than components that you can drop on a pixel form right away. That is harder to do. Look into the TurboPHP source code which was released. It is a monster.
One could use TurboPHP source code for ideas too. i.e. steal the turbophp source code and make a TurboPowtils. But I looked into the source and it is.. really really really monsterous. I doubt very many people could just make a TurboPowtils IDE in a few days by hacking the TurboPHP sources.. but one could always try.
Object Powtils Brainstorming
In fact one way to make a clean OOP framework that doesn't use so many free/create calls is to use old borland objects on the stack for the main web object (web.write, web.geturlvars) instead of using classes on the heap. With a stack based object (no pointer) you can use the object without creating it and freeing it. Other widgets could also be used on the stack. However, many people are used to classes. Many web programs are capable of being stack based since they don't require threads. A cgi program is like a private thread itself, actually.
|
