If you're new to TMS WEB Core, welcome aboard! There's a lot to understand about how TMS WEB Core connects Delphi apps to typical HTML templates and web apps in general, so be sure to have a look through some material first if you're interested in getting a bit more of a footing from those that have come before you...
- This post in the TMS Support Center
- There is a set of "Basics" posts (ongoing!) in the TMS Blog, starting with this one.
- There are numerous other blog posts and even some books by Holger Flick to help things along.
With that out of the way, I'm hoping you're referring to the Template Project that was written about in this blog post (or this GitHub Repository). I created it, so I can hopefully help you understand how it works. Note that this is not exactly the simplest project to start with.
But before we get to that, here are a few notes on how HTML Templates work with TMS WEB Core.
In the simplest TMS WEB Core project, there is a Project1.html file, a Unit1.pas Delphi file, and a Unit1.html file. Typically each Form within Delph is associated with an HTML file, though this is no longer strictly required (referred to as Direct Forms).
Generally speaking, an HTML file is loaded up as part of the Form, and its contents are inserted into the <body> of the document which is essentially what is found in the Project1.html file. The HTML elements of the Unit1.html "template" can be combined with the Unit1.pas (and related Unit1.dfm) Delphi Form components by linking them, pairing the HTML "id" properties in the template with Delphi components dropped on the Form, via the ElementID property using the Delphi Object Inspector or one of the linking mechanisms (right-click on the Form, etc.).
When this method is employed, the Delphi component largely replaces the element in the template with whatever the Delphi component is. This works pretty well when the element in the template doesn't have any children, as this replacement doesn't deal with that scenario. It works best with typical TMS WEB Core TWeb components like TWebLabels TWebEdits and that sort of thing, but any TMS WEB Core-enabled components will work just as well.
When it comes to <div> elements, this is probably not what you want to do most of the time, as in an HTML document, those <div> elements are often used to provide structure to the page. You can still easily reference them from Delphi, particularly if they have an HTML "id" assigned, but you don't necessarily want to link them to something like a TWebHTMLDiv component in your Delphi Form unless they don't have any children. There's also usually no need to - you only need to link components to the HTML elements that you want to replace. Maybe a small handful much of the time.
Most often, you'd take a complete template, such as the AdminLTE template in your screenshot, and as used in the Template Project, and then just replace the elements in the HTML template with Delphi components that you want to update. So title captions, footer labels, that sort of thing. Works great.
The AdminLTE template is a bit more advanced though, often with many levels of nesting using those pesky <div> elements. It is also structured by default to have completely separate pages for each one of its examples.
To make the most of this in Delphi, what I set up was multiple forms that are dynamically loaded (sometimes nested) into one another as the user navigates around the user interface. In this case, the equivalent of the Unit1.html file associated with a Form isn't really a complete HTML page, but rather just the HTML snippet that needs to be loaded into a particular part of the overall page structure. Because the snippet was taken from the AdminLTE template, it includes the same <div> elements and classes that allow the snippet to flow (and be themed) nicely with the rest of the page.
The Template Project starts with a main Delphi Form that encompasses the entire page and loads up whatever is commonly needed by the template in terms of libraries, fonts, and so on.
This Form then loads a second-level Delphi Form that contains things like the header and footer, the main menu, and that sort of thing. In the Delphi side of that Form, there are components linked to the HTML ids that came originally from the AdminLTE template, so that they are a little easier to access from the Delphi side, but this is more for convenience in coding.
This second-level Form then loads the third-level Delphi Form which then provides the detailed content for a given page, like the charts and other sections that you see in the main part of your screenshot and other screenshots for the AdminLTE template. Here, again, a subset of the entire page's HTML is linked to a Delphi Form, and the relevant bits are paired up between Delphi components and HTML id elements. This makes things a little easier to manage as you can build a pretty complex website with dozens of these little subforms rather than trying to build a big monolithic page within one Delphi Form.
Each level (the main page, the "dashboard" level below it, or these individual "subforms") contains whatever pieces are necessary to tie together the menu navigation and other common elements and allow for the dynamic loading and unloading of Forms from the page overall. So if you're looking at a page with a chart on it, the potentially dozens of other pages with other charts are not currently loaded. They are loaded and unloaded as needed, via functions defined in one of these Forms.
It's a bit complicated and is quite different from how the AdminLTE template works normally, but it is just a template. In the Template Project, we just copy the sections of the AdminLTE template we're interested in, into the various Delphi Forms (the Unit.html files) as we go about creating different sections of the app. We're careful to copy all of the parts of the template that are relevant, including all the class names and the <div> structure, sometimes adding in more HTML id attributes where they are missing.
Hope that makes some sense. Happy to help further if it doesn't!