Design Explanations - Part II
Re-using informationHome Page XSLT | Flower pages by color XSLT (template) | Flower pages by name XSLT (revised template) | CSS | JavaScript Functions On both the homepage and sub pages, approximately 90% of the HTML elements are filled with re-used information. The only unique information on the pages are the headings to indicate the name or the color of the flower type. Here, I consider re-used information to include any information that are drawn out from a common XML source as specified in XPath codes in a common stylesheet template and that can be used again and again. I also consider as re-used information everything else on the stylesheet that can be copied repeatedly on all the pages. This include the headings for the tables, labels for the drop-down boxes, contact/business hours buttons and labels for the calculator. On the homepage, the HTML elements containing the logo with slogan, flower images with their names and links to the flower pages, drop-down menus with links to sub pages, and buttons for contact information and business hours are all filled with data from XML sources that can be used several times. The HTML links in the drop-down menus and contact/business hours buttons are transformations of XSLT stylesheets with a common XML source. These are also used repeatedly on the individual flower pages. The flower calculator is repeated on all the flower pages and this can be considered re-used information too. The functionality of the calculator is determined by JavaScript functions that can be called wherever it is needed. I would have to point out however that there is a stylesheet for each of the flower pages. But these individual stylesheets are based on a common template that can be copied several times and then adjusted for a few elements specific to the flower name or color. I could have individualized the flower stylesheets using variables that can be changed easily at the top of the XSLT file but there are only three places where the data can be individualized so I figured that this is not such a big maintenance issue. I have also used CSS style elements to individualize the border colors and other style elements of the flower pages. Perhaps one aspect of the structure of my XML files that I considered regarding re-use is with how I handled images. I basically created 'Image' elements in the XML files to hold information regarding the location of images rather than store these information in a separate XML file purely for images. I thought that putting the images in a separate file requires additional information that would link each image to the corresponding flower type or variety in a separate file. But I may have to rethink this strategy in relation to image URIs. I have pretty much used the same strategy in re-using information as I have done in the first deliverables: put company and flower XML files into a common XML file and then accessed the data in them using the document() function. I have used this common XML file as the sample XML file for all my XSLTs to create the pages on my website. The big change in my second website was creating one XML file for all the flower data using a new XML schema. I don't think my first strategy would have impeded the requirements of the second deliverables because the separate flower XML files all had the same data structure so I could still have referred to elements and attributes common to all the separate XMLs in searching for a string to indicate color. The benefit that I have gained in restructuring my flower data and putting them all into one file is that the structure and semantics make more sense to me (and hopefully my staff) and easier to maintain automatically later. What I have tried hard but failed to do was to create ONE XSLT that would apply to a common XML file without manually inserting information specific to the page I want to create (e.g. color string to be searched, label for flower name or color). I have tried to create templates that match specific parent and child nodes in the XML source but I haven't been successful in coding the whole template so that certain templates apply only if such and such conditions are present. I don't know if this is even possible. I have weighed the cost in time that I would have to put in doing some things manually and some automatically and have decided accordingly. I have decided, at least at this point in my XML proficiency, that it was much easier to copy, paste, and tweak than to spend countless hours trying to see where some looping and conditional statements would work best in the templates. I will continue however to work on these files [FlowerMerge.xslt & mergetest.xslt] to create new XMLs from separate XML files. Linking data sourcesThe shipment and catalog files can be linked using the ID number of the flower variety but I wasn't successful in using the two-table relational model and other strategies to create new XML structures from separate XMLs. The best that I could do was to create a common XML to store all the shipment files [Shipments.xml], another one to contain all the catalog files [Catalogs.xml], and a third one to contain inventory [Inventory.xml]. I plan to use these for the back-end part of my business (not shown to customers) to keep track of inventory, suppliers, shipments, and catalogs in addition to the employee and company files i have created in the first part of this project. Addressing future, unknown, ad hoc requestsSo far, we have covered the name and color characteristics of flowers/plants but there are other characteristics that customers may want to search on or to categorize their needs with such as the full-grown height of the plant, season in which to best grow it, whether it is an annual or perennial, needs full-sun or shade, etc. Customers might also want to know the container size of the plant - whether it is in a 4-inch, quart, gallon, or bigger container sizes. All these require a re-structuring of our data files. The best thing that I like about XML is that it allows for a lot of natural language in labeling our data elements and attributes. It also allows us to search on many possible synonyms of a word. For example, in searching for the color 'red,' I specified that either the 'Text' or the 'Name' element of a variety of a flower type contain either the string 'red,' 'raspberry,' or 'scarlet.' For the color purple, I specified the strings 'purple,' 'violet,', or 'lavender.' I think this serves the needs of the customers for the most part but being able to specify all possible synonyms of a search term in a code can become unwieldy. I'm thinking that perhaps we can impose some control in how our descriptions are stated? I don't think we can control how suppliers describe their products but perhaps my business can standardize descriptions as well as labels for elements and attributes when creating new XML data files from disparate sources. There are other future requests that might come up like the ability to order plants and other products online. I have started coding for an ordering system to go with the calculator using Active Server Pages but I pretty much do most of my coding from scratch and it's just too time-consuming. I would recommend for my business to buy software that has customizable modules for an ordering system. I anticipate other adjustments as my business expands - managing information about a growing staff, inventory, and operations. But one thing I've learned about XML is its flexibility in accomodating changes. It seems to work well in conjunction with many other tools and I intend to study further how we can use it to create better information systems and to manage them better. Other XML filesPicture Credits
|
|||
|
|
|||
