|[ LiB ]|
Dreamweaver library items use the same basic mechanism that templates use, but on a much smaller scale.
A library item is a piece of code, usually representing a page element, that needs to appear repeatedly throughout a website. A library item exists in a document that has an .lbi filename extension, stored in a folder called Library , in the site's Local Root folder, as shown in Figure 20.28. Library items can be inserted into any Dreamweaver document in the site. Like templates, when the original library item (the one in the Library) is updated, all instances of it throughout the site are updated as well. Library items are managed through the Library category of the Assets panel, shown in Figure 20.29.
The most common way to create a library item is by grabbing some existing content in a site document. Just select the content you want to add to the library, open the Library category of the Assets panel, and click the New Library Item button (see Figure 20.29), or choose Modify > Library > Add Object to Library. A new, untitled item is added to the Library (obviously, you'll want to rename it!), and the selected content in your document is turned into an instance of that item. If you check the Site panel, you'll see that a new LBI file named after your library item now appears in a Library folder. If you open this file, you'll see that it contains only the code fragment that was selected when you created the item. Dreamweaver displays it in Design view, as though it were a complete HTML document, but it doesn't include the HTML framework.
You can also create an empty library item by clicking the New Library Item button in the Assets panel when you have no document open or nothing is selected in the current document.
After you've created a library item, you can insert as many instances of it as you like into any document in your website. Just open the document you want to insert into and drag the item from the Assets panel to the spot where you want it inserted, or place the insertion point where you want the item inserted and click the Insert button in the Assets panel, or choose Insert >.
When the library item is inserted, all its code is copied into the document. Any relative URLs (linked pages, images, and so on) are updated so that they will work from the document's location. The code for the library item appears surrounded by special HTML comments (similar to the comments in templates) that tell Dreamweaver this is a library item:
<!-- #BeginLibraryItem "/Library/contact.lbi" --> <a href="mailto:email@example.com">Contact the author</a> <!-- #EndLibraryItem -->
Within the document, the item is noneditable. When you select it, the Library Item Property Inspector appears, as shown in Figure 20.30, giving you three options:
Open Opens the LBI file for editing.
Detach from original Removes the surrounding comments from the item's code, making it editable but no longer connected to the library.
Recreate If the original LBI file has been lost or damaged, clicking this button creates a new LBI file containing the code from this instance.
Like templates, library items are dynamically updateable. Editing the original library item automatically updates all instances of the item throughout the site. To open a library item for editing, select an instance in a document and click the Open button in the Property Inspector, or select the original in the Assets panel and click the Edit Library Item button, or double-click the LBI file in the Site panel. Make whatever changes you like. When you save the file, Dreamweaver offers to update all occurrences, as shown in Figure 20.31. Clicking the Update button copies the code to all documents containing instances of the item.
Every time you update a library item, you have to upload all files containing instances of the item. The easiest way to make sure this happens is to synchronize the entire site (select Site > Synchronize). There's no need to upload the original LBI file to the web server (because the code has been copied into the document files). You can even cloak the Library folder so that Dreamweaver doesn't try to upload it every time you synchronize your site. Do this in the Site panel by right-clicking the LBI file and choosing Cloaking > Cloak from the context menu. Or you can open the Site Definition dialog box, go to the Cloaking category, and add .lbi to the list of filename extensions that are automatically cloaked.
For more on cloaking, see the section "Cloaking" in Chapter 18, "Site Publishing and Maintenance."
After all the complexity and sophistication of templates, library items are refreshingly easy to understand and use. They don't have editable regions, or optional regions , or parameters. But as with everything, they have their own tricks.
Library items don't have anything to do with templates, and they don't require templates to work, but you can use library items and templates together. You can put a library item into the locked region of a template, or into an editable region of a template's child page. The procedure is the same as for inserting library items into nontemplate pages. Why would you want to put library items and templates together? Maybe you have a site with three templates, each of which has a logo/contact/copy-right bar at the bottom. Make that bar into a library item, and place it in the locked bottom area of each template file, and you don't have to update it separately in each of your three templates.
Or maybe you have a catalog site where periodically certain items are on sale and need a special sale notice. The notice will appear at different places within the editable region of each child page, so it doesn't belong in the template itself. But you still want to be able to update it quickly across the entire site. So you create a library item and insert it into editable regions within your template's child pages.
A library item is a fragment of code. Sometimes it's an incomplete fragment. That can be a problemor an opportunity for creative sneakiness. It all depends on how you look at it.
When you insert a library item into a document governed by CSS, the library item becomes governed by that same CSS. If you've redefined the h1 tag for your document, and you insert a library item that contains an h1 tag, the instance won't look the same as the original in the library. If you insert the same library item into another document that has h1 defined differently, that instance of the item won't look the same as the first instance. Similarly, if the library item calls on a custom class, that class might be defined differently in different documents, creating different-looking instances of the item across the site.
If you plan your styles right, you can use this CSS dependence to create multipurpose library items that blend nicely into the pages they're put into. The formalwear section of your site has blue subheadings; the beachwear section has orange subheadings . The sale notice you drop into both sections gets automatically color -coded to match its surroundings. Nice!
If you want to guarantee that all pieces of the library item are styled the same throughout the site, your best choice is to put that styling into an external style sheet that all pages in the site are linked to. But if this solution isn't feasible , you can always use an inline style within the library item itself:
<input type="text" name="username" style="width:150px" />
This overrides any other styling present in any documents the item ends up in. Of course, you can't use the CSS Styles panel to apply this styling because Dreamweaver doesn't support inline styles. You have to either code it yourself in Code view or use the Tag Editor dialog box or the Selection Inspector.
Dreamweaver behaviors are always coded with a function placed in the document head and a function call in the code for the page element the behavior is attached to. When you create a library item from a page element, only the function call goes in the library; the function itself remains behind.
This might seem like a terrible problem, but it's not. Dreamweaver is pretty smart about behaviors. After you insert the library item into a document, Dreamweaver sees the function call and automatically inserts the required function along with it. Pretty neat trick!
When you create an image map in Dreamweaver, the program inserts code in two places, not always together. The map tag containing the hotspot coordinates and links is inserted toward the bottom of the body tag. The img tag that uses the map is placed wherever the image appears. If you select the image and turn it into a library item, only the img tag goes to the library; the map stays behind.
To make sure that this doesn't happen, you need to do a bit of code tweaking before creating the library item. Go to Code view in the document containing the image map. Find the map tag and move it so that it's right next to the img tag. The code should look something like this:
<img src="usmap.gif" width="473" height="181" border="0" usemap="#Map"> <map name="Map"> <area shape="rect" coords="103,88,216,119" href= "district1.html"> <area shape="rect" coords="226,89,340,119" href= "district2.html"> <area shape="rect" coords="349,89,464,120" href= "district3.html"> </map>
Back in Design view, the map appears as a gold icon next to the image, as shown in Figure 20.32. Make sure that both are selected before creating the library item.
If you've already created your library item, and the map didn't make it into the code, just cut and paste it from the original document into the LBI file.
Library items are good and efficient at what they do, but they have one drawback: Every time you update a library item, you have to upload all the files that contain instances of that item to the web server. What if you use the item on two dozen pages or more, and the information in the item changes frequently? You'll get pretty tired of uploading and reuploading, especially if the uploading takes a while. This is a case for a server-side include.
Server-side includes can serve some of the same purposes as library items, but they're very different. They're part of the HTML specification, not just Dreamweaver tools. A server-side include , or SSI , is a placeholder that sits in an HTML document, containing instructions to the web server to replace it with some dynamically generated data. The data inserted can be anything from a chunk of predefined code to the current date or time to information collected from processing a script or querying a database. Or the data inserted can simply be another fragment of code, stored in another HTML file, to be tucked as-is into the current document. That's just like a Dreamweaver library item! The difference is, the web server (not Dreamweaver) does the inserting, and it happens at the last minute, when the page has been requested by a browser. This means that if you change the included file, you need to upload only that one file to the server, not any of the files that might call on it. For frequently updated pages, that's a big time-saver. Figure 20.33 compares the processes for library items and server-side includes.
Be aware that because SSIs require extra processing duties from the server, not all servers are configured to handle them. Before using them on any site, check with your server administrator or tech support staff to find out if they're supported.
A server-side include consists of a code fragment file, with an .htm or .html filename extension, and one or more documents that call on it. Each of these files has the .shtm or .shtml filename extension. (The "s" alerts the server that it needs to perform extra processing before delivering the page to a browser.) In Dreamweaver, the job of putting the include into the parent file is done with the Server-Side Include object. The whole process works this way:
In Design view, Dreamweaver displays the page with the inserted file in place, as shown in Figure 20.34. If you look in Code view, however, the code looks like this:
<!--#include file="myfile.html" -->
When you select the include, the SSI Property Inspector appears, showing the name of the included file and the type, which defaults to file .
Because a server puts the include in its parent file, it can't be previewed locally. If you have Dreamweaver configured to preview using a temporary file (do this in the Preferences/Preview in Browser dialog box), when you preview, Dreamweaver inserts the SSI code into the temporary file, along with some proprietary code indicating that this is an SSI. If you are not configured to use a temporary file, when you preview, the SSI won't show up at all.
|[ LiB ]|