[ Pobierz całość w formacie PDF ]
.Instead, it can be a fieldwithin the table of menu entries.Each entry needs a name, which is the text to bedisplayed when the menu is rendered in a browser.It also needs a link to define thedestination for the menu item.This is best stored as a relative URI for local links anda full URI for external links.The other structural attribute of a menu entry is the ID of its parent, if any.Obviously, this applies only to entries in submenus, with top levelmenu entries given a special value for parent, with zero being the obvious choice.Additional information is needed for the management of menus.An indicationis needed to show whether or not the menu entry is published, and a sequencingnumber can be used to control the order in which menu items are displayed.Agenerally useful facility is to store data to identify any menu entry that is checked out for editing by some administrator.[ 186 ]Chapter 9Menu ManagementMost of the requirements on menu management are implicit in the description ofthe data given above.A particular menu can be shown to an administrator in fullyexpanded form, including submenus, as a list of items.Some visual cue such asindentation helps to identify submenus.Operations such as deletion or reorderingare straightforward.The demanding part of menu management is the creation ofnew entries.Obviously, one way to create a new entry would be to ask the administrator toprovide all the information, including the URI that defines the entry's destination.When the URI is external to the site, clearly that is what has to happen.But for links within the site, it would be very unhelpful to demand that theadministrator figures out the URI.It is useful to permit that to be done, and to treatlinks created in that way precisely the same as links created using assistance from theCMS.This is achieved by the design decision to abandon keeping anything within aURI to connect it with a menu entry.When the menu item is chosen from a menu bya user, the only information that is received by the CMS is the URI.Thus, two linksthat have the same URI will be treated in exactly the same way, regardless of howthe URI was derived.Helping the administrator to create menu entries really comes down to presentingchoices in meaningful terms.Apart from a few special cases that are handled bythe CMS framework, every URI is a way to invoke a component.It has an ancillaryfunction in defining the other contents of the page that will be returned to thebrowser, but its primary effect is to cause component processing.Thus, the firstchoice the administrator must make is to select a component from all those that areinstalled in the CMS.That may be sufficient, since every component will have somedefault action that it carries out when invoked with no other parameters.Sometimes, menu entries might be needed that point to particular functions withina component.Suppose the component is quite generalized in handling articles, say,as in a magazine.If no parameters are given, the component will probably displaysome top level table of contents or the introductions from a selection of articles.But it will also be desirable to be able to create menu entries that point to a specificgroup of articles, or even to one specific article.The administrator can build menuentries much more easily if presented with a choice of names for groups of articles,or a choice of article titles, rather than being expected to come up with a URI thatprobably uses apparently meaningless numbers for this information.[ 187 ]MenusHow is the framework to cope with the huge variability that can arise incomponents? There is no end to the possible ways to construct a URI in the generalcase.The obvious answer to this is that the framework cannot do the whole job, butneeds to involve the component.Earlier systems included a great deal of special codewithin menu administration that catered to a limited range of built-in components.This is undesirable, as it works against the "pluggability" of new components.The better solution is to remove all component specific code into the component itself.The implication of this policy is that there must be a defined interface that anycomponent can provide for menu creation.Once the choice of component hasbeen made by an administrator, the remainder of the URI creation for a menu itemcan then be handled by exchanging information between the CMS framework,and the component's menu creation interface
[ Pobierz całość w formacie PDF ]