Create your Website content with Delphi!

Every time I have to create some kind of Webpage, I have to decide how to build the dynamic content. 

This is a follow up of my other blogpost about: "How to write you own Serverside-Extention!"

In the old days, it was easy! You had to provide a Webpage with a maximum horizontal resolution of 800px because this was the most used "device" (PC) resolution used by the visitors.

To keep the navigation of each page in only one place, your main design was a framed page setup. I still love this concept and I really dislike this horrible "scroll down to the earth core" pages. Of course on a smartphone, the frame concept does not work anymore.

To build a nice maintainable page you can use ASP.NET. With ASP.NET it is easy to create a master page and content pages. The server takes care of combining these two (or more) files at runtime, in nearly any other case you have to copy the navigation to each page.

Btw. if you like PHP, don't talk to me... ;-)

Creating webpages with ASP.NET and Delphi is nearly the best you can do. You have the JIT compile that creates your background binary code for direct execution, you have "native" code that is executed by the IIS and your pages are super fast. No need to stop the IIS to change the DLL or anything else.

Too bad EMBT/CodeGear dropped the support of ASP.Net after D2007. Yes, the HTML designer was bad and after D2007 there was prism. I've done some pages with prism, but this is not the same.

There is another thing called VCL for the Web. This works with Delphi forms and really long state data for the back button. This works also fine but is a completely different thing.

The other possibility is a Webbrocker application. This could be used on Linux and Windows. With a loader that is able to unload and update your DLL (Windows) you can easily update to new versions. 

If you want more information about this topic, please follow the link above.

The IIS will create a new thread for the request and executes your DLL. This is fast as hell because this is a really native CPU execution of your code. The final content as a string or a result stream is handled from the IIS and transferred to the user.

With this kind of DLL every single char/byte is streamed from your Webbrocker-Application and you have 100% control of the final result. You can load a page from the disk and process it - change tokens to different content or create a complete table from a database. This is fast, that is not the problem, but often you have to provide extra HTML content to format your final result and this is a little drawback.

Your Webbrocker application could also be used as a RESTful Webservice and the result could be XML, JSON, or SOAP, but this is not the topic for today.

For example: If you want to present a list of persons nicely formatted, you could change a token <#PersonList> in your HTML-Page to a list of persons from the database.

Let's ignore for the moment that most HTML-Editors dislike this kind of token.

You have to format the content with additional HTML-Tags like <br /> or <ul> and <li> or even a <table> with CSS. If you have a page that is static for a long time - no problem. But with every change of the presentation, you have to change your source code, recompile and upload a new DLL.

You could use an async call in javascript to your DLL for a REST-Call and process the JSON result also with javascript to the final HTML, but this is horrible from the viewpoint of a Delphi developer.

So what to do?

For many years I've used the Webbrocker approach and it works for me. This time I have the first project where the Webdesigner is unable to use Delphi and the Delphi developer has no clue about Webdesign or Javascript.

Well, Delphi Webscript (DWScript) is perhaps one possibility, but this is much too Delphi driven.

After some research, I found a project from Marco Cantù implementing Razor. Razor is also for C# and ASP.NET, but Marco's implementation is using the Webbrocker to process the HTML-Pages that contains the Razor @ Syntax.

This is really nine, the syntax is given and the HTML-Editors do like the tags with @Whatever more than the Webbrocker tags. The implementation for loops is "Javascript-Like" and it is very easy to include HTML-Tags into a loop for displaying data from a database or a simple loop. So the Webdesigner is able to change to look, without a recompile of the DLL. One thing I dislike with this approach is: 

• You have to compare every byte in the source HTML to find the @-Tag
• You have to syntax check the HTML-Source
• You have to replace the @include Tags after all the processing.

Perhaps your server is fast enough to do this byte by byte comparison for every request in real-time, but this is against every rule that is deeply implemented into my development soul. 

Perhaps I should implement a converter to process the HTML-Pages and create a jump-table to do the trick? With a jump-table, you do not need to search for the @ token... There is still the include page tag problem, but if the included page has also a jump-table is more like a "just-stream-copy" thing than processing a string replacement...

After one day...

I call it a JIT-Compiler.

If the Webbrocker wants to load an HTML-Page I have to check if there is a ".htbin" file with the same timestamp. So I use findfirst not fileexists to check this (with findfirst I get the SR and the Timestamp). If there is my bin file, I'm done and I can use the prechecked bin-format -file with the Jump-Table, if not I will use the normal processing for the first time and create the bin file on the fly for the next request. This is really fast and I like this idea.

Should I include a Delphi-Script tag to process Delphi source? Perhaps in the future.

Do you want to see a Webinar for this? 

Do you want to use this for your own projects? Should I do a git fork of Marco's repository and put this on github?

Please leave a comment...

And as always: Please visit my youtube and hit subscribe to help me grow my channel!