# Developing Large Web Applications- P7

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:10

0
36
lượt xem
5

## Developing Large Web Applications- P7

Mô tả tài liệu

Developing Large Web Applications- P7:This book presents a number of techniques for applying established practices of good software engineering to web development—that is, development primarily using the disparate technologies of HTML, CSS, JavaScript, and server-side scripting languages. Whereas there are many books on how to use languages, how to use libraries, and how to approach software engineering, this is the first book to codify many of the techniques it presents. These techniques will make the components of your own web applications more reusable, maintainable, and reliable....

Chủ đề:

Bình luận(0)

Lưu

## Nội dung Text: Developing Large Web Applications- P7

1. Don’t confuse the id attribute with the name attribute. In various form inputs, the name attribute lets you give names to input values; these names are passed along with the values for scripts on the server side. Conventions for Naming There are a lot of opinions about naming conventions for IDs, classes, and names, but everyone can agree that establishing some sort of convention is important. In large- scale HTML, a good naming convention is key to modularity. One convention, dem- onstrated earlier in Example 3-3, is to use short groups of three to six characters for naming (e.g., nwcrev is the ID for the New Car Reviews module). From here, you can append other name segments of three or four characters to create further qualified names for use deeper within the module (e.g., nwcreveml for the id and name attributes of the email address text field). Using fully qualified names like this promotes modularity because you can be assured that anywhere you use this module, its names will not conflict with those used by other modules. For example, if you were to place the New Car Reviews module on a page with another module that also contained a similar form input field for an email address, this naming convention would ensure that the inputs of the two modules would be passed to the server-side script with different names. Because using short, augmentable name segments is compact and works well, it’s the convention that we employ throughout this book. That said, the exact convention is not what is important here; whatever conventions you prefer, establishing a system of unique qualification that ensures modularity is the key. XHTML For quite some time, HTML has implied HTML 4.01, but browsers have been very forgiving of code that did not meet precisely with this specification. In fact, many egre- gious transgressions are politely rendered by the browsers in a reasonably elegant way. That said, this forgiving attitude by browsers has been a double-edged sword. On the one hand, it plays an essential role in ensuring that older documents can survive on the Web with little or no modification. On the other hand, it gives web developers a lot of room to be sloppy. XHTML establishes a more rigorous definition of HTML that for- mally helps web developers alleviate some of this sloppiness. Benefits of XHTML XHTML 1.0, the latest version of XHTML from the W3C to advance past the working draft stage, is a reformulation of HTML 4.01 in XML 1.0. This reformulation provides additional rigor and formality that earlier versions of HTML were never intended to have. Because XHTML conforms to XML, it offers web developers several benefits. XHTML | 41
2. First and foremost, XHTML’s strictness results in cleaner, more consistent code that promotes better maintainability and reliability. Next, XHTML is readily viewed, edited, and validated with standard XML tools. In addition, XHTML can utilize applications that rely upon either the HTML DOM or the XML DOM. Finally, XHTML is more likely to interoperate within various XHTML environments in the future should XHTML continue to advance. Since XHTML can be written to operate in older brows- ers as well as in XHTML-conforming browsers, there are few reasons not to start writing HTML using this higher standard. XHTML Guidelines Fortunately, it is relatively easy to make the HTML that we write conform to the higher standards of XHTML. The examples of HTML in this chapter, as well as in the rest of the book, are actually XHTML, for the most part. Most HTML is compatible with XHTML, but there are a few guidelines that you need follow to ensure your code conforms to XHTML while continuing to render properly in older and XHTML- conforming browsers alike. A list of these guidelines is presented below. Proper nesting of tags In XHTML, tags must be nested in such a way that tags are closed in the exact reverse order that they were opened. For example, Example 3-3 contains the following, where the tags are properly nested: 2009 Nissan Altima (from $19,900). Consider, in contrast, the following example, where the strong tag is closed before the em tag. This does not conform to XHTML: 2009 Nissan Altima (from$19,900). End tags and empty tags In XHTML, every tag must have a corresponding end tag. In HTML, web developers frequently leave off closing tags for elements such as list items and paragraphs because browsers can infer where these tags should be closed. In XHTML, you must provide the end tags explicitly. Example 3-3 includes the following text, where we have correctly closed all list items: 2009 Toyota Prius (from $22,000). Read the review 42 | Chapter 3: Large-Scale HTML 3. 2009 Nissan Altima (from$19,900). Read the review Contrast that with the following example, where there are no end tags for the list items. This does not conform to XHTML: 2009 Toyota Prius (from $22,000). Read the review 2009 Nissan Altima (from$19,900). Read the review The requirement for every tag to have a corresponding end tag can make tags like br rather tedious to use; you would need to use in XHTML wherever you had been using in HTML. Fortunately, there is a shorthand for tags that enclose no content: include a forward slash before the closing bracket. Although XHTML allows a construct such as to accomplish this, it is advisable to put a space between the tag and the forward slash, like , to protect against compatibility problems in HTML browsers. In Example 3-3, we use an input tag (which always has no content), correctly terminated with a space and a forward slash: Contrast this with the following example, where there is no forward slash before the closing bracket. This does not conform to XHTML: Using the shorthand notation can be a handy way to denote empty content for any tag. For example, if you had an empty paragraph, you could write instead of writing . The following HTML tags appear in Table 3-2 and never have content: XHTML | 43
4. Case sensitivity In XHTML, every tag and tag attribute is case-sensitive and defined in lowercase. In Example 3-3, we have the following for the label tag, where we see lowercase for the tag and its for attribute: Email In contrast, the following example puts the tag and its attribute in uppercase. This does not conform to XHTML: Email Attribute values In XHTML, all attribute values must be quoted using double quotes. In Example 3-3, we have the following, where we used double quotes: In the following example, the attribute values use apostrophes (single quotes) or omit the quotes around the values altogether. These practices do not conform to XHTML: Furthermore, you must specify an explicit value for all attributes that you use. This means that attributes that often are shown without values in HTML must be assigned something in XHTML, even though this may feel pedantic. Set these attribute values to a value the same as the name of the attribute (e.g., checked="checked"). JavaScript, CSS, and special characters JavaScript, CSS, and the special characters that these may contain require some special treatment in XHTML. Whereas in HTML you can wrap sections of embedded Java- Script and CSS between , XML browsers may ignore the sections. On the 44 | Chapter 3: Large-Scale HTML
5. other hand, if you place these sections in a CDATA block, HTML browsers will ignore the CDATA contents. The ideal solution is to link JavaScript and CSS via external files, which is a good practice anyway. However, there may be times that you cannot do this entirely. In these cases, your document will not conform to XHTML. XHTML is also sensitive to certain special characters. In XHTML, you need to replace greater-than signs, less-than signs, and ampersands wherever they appear in text nodes, JavaScript, and CSS with their character entities (e.g., &lt;, &gt;, and &amp; or their numeric equivalents). As a result of these issues, many developers set their document types to the HTML 4.01 Strict DTD, even if coding to take advantage of XHTML’s benefits. This lets you con- tinue to validate your document using HTML validators while coding to the higher XHTML standard, albeit with a few compromises for now. RDFa Even when you have created a good information architecture for a module in HTML, there is only so much meaning that you can communicate in a standard way using the small collection of elements that HTML provides. RDFa (Resource Description Frame- work with Attributes) is an emerging technology for extending your HTML to provide additional meaning. It has special significance for the Semantic Web. The Semantic Web is an evolving extension of the World Wide Web in which web developers define the semantics of information and services so that the Web can understand and satisfy re- quests for content made by people and machines. A key characteristic of RDFa is that it defines a standard way for web developers to annotate information further within pages that have been built for visual consumption. In this sense, RDFa attempts to unify the “human Web” (the one we see published as web pages) and the “data Web” (the one increasingly consumed by applications via web services). If we are part of the growing web community that believes that websites should be open for humans and machines to consume alike, we should consider ex- tending the information architecture of our modules with RDFa. Microformats were an earlier attempt to add meaning beyond what HTML was able to provide. Microformats define standard structures using HTML tags and classes to represent certain commonly occurring data structures. RDFa has much loftier and more extensible goals in mind. RDFa Triples RDFa is fundamentally about creating triples that consist of a subject, predicate, and object to form statements. The subject is what you are making a statement about. The predicate is the relationship that the statement defines. The object is the resource with RDFa | 45
7. each strong element itself. The value dc:title for the predicate comes from the Dublin Core vocabulary. To use this vocabulary, we have to define a namespace and refer to it using the xmlns:dc attribute, typically within a higher-level element of the page, such as the body element (see Example 3-6). Example 3-5. The New Car Reviews module annotated using RDFa New Car Reviews The Car Connection 2009 Honda Accord (from $21,905). Read the review 2009 Toyota Prius ($22,000). Read the review 2009 Nissan Altima ($22.95). Read the review Get our most recent reviews each month: Email Example 3-6. Namespace definition for the Dublin Core vocabulary . . RDFa | 47 8. . Table 3-5. Triples from the RDFa attributes in Example 3-5 Subject Predicate Object http://.../reviews/00001/ dc:title 2009 Honda Accord http://.../reviews/00002/ dc:title 2009 Toyota Prius http://.../reviews/00003/ dc:title 2009 Nissan Altima Example 3-7 presents a further enhancement to the information architecture presented in Example 3-3 for the New Car Reviews module. In Example 3-7, we have annotated the title and creator for the reviews as a whole. In addition, we have used the content attribute to change the object of the triple for each review. By doing so, we can provide something more descriptive than what appears in the markup. Altering the content like this can be useful when you need to use different representations of information in the human Web and the data Web (the human Web did not require this clarification in the title, for example). The enhancements in Example 3-7 produce five triples (see Table 3-6). Example 3-7. The New Car Reviews module annotated further using RDFa New Car Reviews The Car Connection 2009 Honda Accord (from$21,905). Read the review 2009 Toyota Prius (from $22,000). Read the review 2009 Nissan Altima (from$19,900). 48 | Chapter 3: Large-Scale HTML