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:
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 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.
TODO:
top