However, one of the main things I was looking for was reuse of components. The parameters that drive the items in this ticker were provided in an array and the look-and-feel was determined by variables within the application code. Because the rest of the script was what I wanted and looked relatively simple to rework, I decided to rework the script so that I could declare the news items and the look-and-feel in each page that needed the ticker, while continuing to use the same core script.
Restructuring the existing code
The first thing I did was to work through the code and change the layout so that it was easier to read and amend as I wanted. At regular intervals, I reorganized the script and retested it, using the sample file provided in the download file. This ensured that I had not accidentally messed up the functionality of the code as I converted it into a more readable and amendable format. The original code can be seen in Listing A and the revised version in Listing B, a working example using the revised version can be found in Example A.
Apart from making the script a little more difficult for the casual surfer to copy without credit, the original file is also smaller as it does not contain the spacing characters—such as the tabs and the carriage returns—present in the Listing B, or any comments. In this case I have added 1k to the file size by doing this. It is possible to see that in some cases removing the human readability element while maintaining the computer readability element may give a performance enhancement to any code that you produce.
Separating the elements out
The on screen ticker itself has three main parts: the main ticker box—comprising a space for the headline and a space for the news item—the news headline box, and the news item box as shown in Example A.
Now that you have the script in this more accessible format, the next task is to split the script into two parts. The first part is made up by the sections that will form part of the configuration section and the static code library for the rest. For this article, I have assumed that all the options that will become part of the configuration section will be populated, even with a null or empty string, every time the script is used. You may need to write some code to ensure that this has happened or handle a situation where it does not.
Looking at the script, the following elements will become part of the configuration section:
- Anything that determines the look and feel of the ticker, e.g., colors, fonts, etc.
- Anything that contains data relating to the news elements to be displayed in the ticker
Now that you have separated out the two components of the ticker, you are able to configure two completely different ticker styles—see Example B and Example C—while using the same common core source file.
Introducing XML to the mix
Now that you have this working, look at how you could make the provision of the unique elements of the script easier to manage for the end users, or even separate them out from the individual pages if the news items or the look-and-feel were to be common across several pages. With this in mind, I decided to define them in an XML DTD and then each ticker could be driven by an XML file.
Take it further
I have looked at how you can convert a single use DHTML News Ticker into a reusable component and how you can provide the parameters to this new Ticker via XML. There is obviously plenty of scope for taking this further; you could, for example, add the look-and-feel elements to the XML file or add a handler into the code so that default values are provided, but I leave that up to the creativity of the reader.