English | 2012 | ISBN: 978-0-321-81218-6 | 228 Pages | PDF, EPUB | 18 MB
A flexible wiki library might provide application writers with a choice of markup languages, since many different popular formats have emerged over the years.
To make this work, we need to separate the functionality of extracting the contents of user-created markup source text from the rest of the wiki functionality, such as account management, revision history, and content storage. The rest of the application should interact with the
extraction functionality through an interfacewith a well- documented set of properties and methods. By programming strictly to the interface’s documented API and ignoring the implementation details of those methods, the rest of the application can function correctly regardless of which source format an application chooses to use.
Let’s look a little more closely at what kind of interface is needed for wiki content extraction. The library must be able to extract metadata such as page title and author and to format page contents as HTML for displaying to wiki readers. We can represent each page in the wiki as an object that provides access to this data through page methods such as getTitle,getAuthor, and toHTML.
Next, the library needs to provide a way to create an application with a custom wiki formatter, as well as some built-in formatters for popular markup formats. For example, an application writer might wish to use the MediaWiki format (the format used by Wikipedia):
How would a formatter such as Wiki.formats.MEDIAWIKIbe implemented? Programmers familiar with class-based programming might be inclined to create a base Pageclass that represents the user-created content and implement each different format as a subclass of Page. The MediaWiki format would be implemented with a class MWPagethat extends Page, and MEDIAWIKIwould be a “factory function” that returns an instance of MWPage:
(See Chapter 4 for more about implementing class hierarchies with constructors and prototypes.) But what practical purpose does the base Pageclass serve? Since MWPageneeds its own implementation of the methods required by the wiki application—getTitle, getAuthor, and to HTML—there’s not necessari ly any useful i mplementation code to inherit. Notice, too, that the displayPagemethod above does not care about the inheritance hierarchy of the page object; it only requires the relevant methods in order to work. So implementations of wiki formats are free to implement those methods however they like.