|
[ Pobierz całość w formacie PDF ]
.Providedthe ID is set correctly, active menu highlighting is straightforward and page layoutcan also be determined.The problems are those indicated above.Creation of thecorrect ID can become extremely difficult, and failures could result in displayingpages that are not what the site designer actually intended.Forever needing togenerate an ID for each URI causes extra code to be written.Page Management by URII assume that there is no strong reason to try to separate the page layout, and menuitem highlighting issues.When they were first raised above, it was mentioned thatboth had to be connected with common factors in the URIs used within the site.If thepage layout were separated from menu highlighting, we would need an additionalscheme for linking a URI pattern with a particular page layout, instead of using amenu entry.There seems little to be gained, since we can always introduce an extra"hidden" menu to handle any URI that we need as a reference point, but which does not occur in any actual menu.So from here on, the menu system is regarded ashaving the extra responsibility of controlling page layouts.The obvious alternative to relying on some kind of ID is to create purely functionalURIs without any extra menu entry identifier.On balance, this seems the bettersolution.The problem of creating an ID in each link is removed, which takes with itquite a lot of code and a difficulty that sometimes defeats developers.In its place anew problem is created, that of recognizing a URI in relation to those that are storedas part of menu entries.On the whole, this move offers worthwhile gains.The code that is removed wouldotherwise be scattered across the CMS.The new problem that is created can behandled at a central point within the CMS.It is only when the site starts to handle anew request, defined by its URI, that the work of recognizing patterns in the URIis required.Before we consider how to make URI recognition work, another assumption needs tobe made clear.For a variety of practical reasons, with security not least among them,the CMS framework has a single entry point.The natural form of URI is thereforethe name of the PHP file that forms the entry point (normally index.php) followedby a query string.PHP has built-in support for handling query strings.However,people often dislike the appearance of query strings, and they have sometimes beenthought to be a handicap for search engine recognition.Although query strings donot actually seem to worry search engines, introducing more relevant words into aURI may help with search engine optimization.The assumption being made here is[ 185 ]Menusthat, even if the URI may be translated into some more attractive form when visibleto users, it is translated back into its standard query string form before making anyattempt at recognition.An essential principle that has to be applied to URI recognition is to look for the mostcomplete match between the URI, and the possible menu entries.What is really beingmatched is the query string, which consists of values for one or more variables.Inpractice, POST data needs to be added since relevant information may be passed inthrough forms.A match on more variables is always favored over a match on fewer.This is based on the reasonable assumption that lower levels of menu structures arelikely to point to more detailed parts of the CMS.Special attention must be given tothe value that determines which component will run.An alternative approach can be used when there seems to be no match.Since wehave already committed to running a session for everyone who does not make thisimpossible by refusing cookies, it is possible to keep a record of the last highlightedmenu entry.If the next URI cannot be recognized, then a simple solution is to assumethat the same menu entry is still active.While neither of these mechanisms is entirely reliable, the overall results seem tobe satisfactory, and at least as good as the alternative and more costly system ofrequiring an ID within each URI.Menu Database RequirementsWith a conclusion to the difficult problem of page recognition and active menuhighlighting, we can return to the more fundamental question of how to store menuinformation.In fact, a single table is sufficient for the menu data, with a second table needed to define which module blocks will appear on a page.Although there are often multiple menus, the only property of a whole menu is anidentifying name [ Pobierz całość w formacie PDF ] |
Archiwum
|