Mark up your website in XML

XML is great for building websites, since it allows you to define your own structure, and use XSLT to convert your XML files to HTML. This means you can define stuff common to all pages, like logos or menus, in a single place in the XSLT template. However, not all browsers are equally well equipped to handle XSLT. It is therefore best to do the transformations offline, and upload the generated HTML files to your website. The setup below shows how this may be accomplished using DIP components:

Website example

In this example, the TDipDirectoryLister component named AllXml recursively lists all *.xml files in the local directory. The TDipNewerChecker component named ChangedXml compares the XML files with any generated HTML files. Only XML files that are newer than the corresponding HTML file, or XML files for which no HTML file has yet been generated, are passed along. The XmlToHtml component generates the HTML files from the XML files, using an XSLT stylesheet. The resulting HTML files are fed into the ViewHtml component, that displays them in a browser for visual inspection. The TDipConfirmer component named ShouldUploadHtml presents a confirmation dialog, asking whether the HTML files should be uploaded. If not, the files are fed into the DeleteHtml component, so that they will be regenerated next time. Otherwise, they are fed into the TDipFtpUploader component named UploadHtml, which uploads the files to the website using FTP.

The TDipDebugger component at the lower left corner is for debugging purposes only. It has a Destinations property that is a set of ddFile and ddWindow, meaning it can send its output to a debug window, a file, or both. The Items property determines what items get logged. It is a set of diRun, diInput, diOutput, and diTiming. The image below shows the debug window in action with just diRun enabled:

The debug window

The image above shows that XmlToHtml fires three components: ViewHtml, ShouldUploadHtml, and DeleteHtml. Of course, it is also linked to UploadHtml, but in this example the user answered "No" to the upload question, so that component never got to run.

So for complex networks, with lots of conditional branches, the debugger component shows you exactly what the execution path is. And all you need to do to get it working, is to drop it on the same data module as the DIP components you want to trace. Debugging is implemented very high in the DIP class hierarchy, in TDipInformationProcessor. The only thing that descendant components may want to do, is override GetInputAsText, and GetOutputAsText, like TDipFileProcessor has.

top

Assemble your GUI from blocks

TODO:

top