Appendix B. Development Tools- P2

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

Thêm vào BST

Báo xấu

52
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Cuốn sách này mô tả cách tạo ra các ứng dụng bằng cách sử dụng Mozilla. Nói chung, tất cả các phần đó đi vào một ứng dụng (bao gồm cả XUL, CSS, XBL, và DTD tập tin) cần phải được xây dựng bởi bàn tay kể từ khi không có công cụ phát triển làm sẵn hoặc các ứng dụng phát triển hoàn chỉnh có sẵn mà có thể làm cho các quy trình hướng dẫn sử dụng dễ dàng hơn. Tạo tất cả những tập tin này bằng tay là một cách tuyệt vời để làm quen với...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Appendix B. Development Tools- P2

Appendix B. Development Tools- P2 B.3. The DOM Inspector The DOM Inspector tool, which is now installed by default in the Mozilla browser and accessible from Tools > Web Development, displays the document object mode of any document or part of the interface and allows you to update that DOM dynamically by changing attribute values, rearranging the structured content, or deleting nodes. The DOM Inspector reads the DOM of the requested window or document into memory, where you can manipulate it. However, the DOM Inspector does not persist your changes back out to the file from which that DOM was originally loaded. If you use JavaScript in the interface or to manipulate web pages, then you will recognize what a powerful tool it can be -- particularly given how hard it can be to see the interface's object model clearly and figure out which nodes in the DOM correspond to which parts of the displayed interface. The DOM Inspector also allows you to inspect local files and URLs. To open a file for inspection in the DOM Inspector, choose either File > Inspect a Window or Inspect a URL . . . and enter the URL of the web document you want to inspect in the dialog. When the DOM Inspector loads a document, it displays the DOM (as shown in Figure B-1 of that document) as a tree structure on the lefthand side and the individual nodes with their attributes and other information on the righthand side. Figure B-1. The DOM inspector interface
As you click on the nodes in the tree in the left panel, the DOM Inspector highlights the nodes that are part of the visible interface by pointing them out with a blinking red border. You can peck through the tree in the DOM Inspector and find all parts of the interface. The DOM Inspector also displays any anonymous content that is part of the window. See Chapter 7 for information about anonymous content and the way it relates to the DOM. The anonymous content nodes that are bound to the window you specify become part of the DOM that the Inspector reads and can be analyzed and manipulated like any other node.
The pull-down widgets to the left of the pane headers let you select which portions of the DOM are displayed in the panels. By default, the DOM nodes are displayed, as shown in Figure B-1, but you can also display the associated stylesheets, the JavaScript objects, the XBL bindings, the document's box model, and other information. B.4. The Component Viewer The Component Viewer is a Mozilla application that displays all components and interfaces available to the XPCOM developer on the Mozilla platform. It is not installed by default in the Mozilla browser, like the DOM Inspector, but you can get binary installations that have it or you can build it from mozilla/extensios/cview if you use CVS. Discovering components and interfaces is actually one of the trickier aspects of developing applications with Mozilla, so this tool can help you when you are at the initial stages of your application development and want to see which XPCOM components and interfaces are available. As shown in Figure B-2, the Component Viewer interface, like the DOM Inspector, has two main panels. The left side shows all components in Mozilla and the right side shows all interfaces. Figure B-2. An interface displayed in the Component Viewer
In XPCOM, a single component can implement more than one interface. Thus, for example, the editor shell component (@mozilla.org/editor/editorshell;1) implements nsIURIContentListener, nsIEditorShell, nsIEditorSpellCheck, and others. If you open the interfaces, you will see the various methods those interfaces define. You can also right-click in the component viewer and access a context menu that lets you look up the selected item in LXR, which is the web-based source viewer for Mozilla.
B.5. Venkman: The JavaScript Debugger Venkman is both a graphical and a console debugger. It is one of the most sophisticated examples of a Mozilla application and an indispensable tool for the many developing applications and web pages that rely on JavaScript. Like the DOM Inspector, you can access the JavaScript Debugger from the Tools > Web Development menu (if it was selected during the Mozilla install process). Figure B-3 shows Venkman in action. Figure B-3. The JavaScript Debugger
Features such as breakpoint management, call stack inspection, and variable/object inspection are available from both the graphic interface and the console commands. The interactive console allows execution of arbitrary JavaScript code in the context of the target application and in the debugger's own context. Profiling measures the execution time of JavaScript functions during debugging, and pretty printing can re-indent and line wrap a poorly formatted function. Keyboard shortcuts for the step commands are the same as in other common visual debugging environments, and console users should be familiar with Venkman's break, step, next, finish, frame, and where commands. Venkman consists of eight main interface elements, referred to as "views." These views display information such as local variables, source code, and the interactive console. They can be detached from the main window to save space on your desktop, or they can be hidden. The Venkman project page at http://www.mozilla.org/projects/venkman/ describes these views and their modes of operation. Users can use a JavaScript API to add to the set of commands and views provided with Venkman. These add-ons can be shared among a project team or provided to the general public. The details of that API are not yet documented, but examples are found in Venkman itself. If you install Venkman, chrome://venkman/content/venkman-commands.js and chrome://venkman/content/venkman-views.js will contain Venkman's default commands and views. The following sample session introduces you to the basic commands and use of the JavaScript Debugger. This sample session is based on the version of
Venkman available at the time the book was written. To find out how to use the latest version of Venkman, read the Venkman walkthrough at http://www.mozilla.org/projects/venkman/venkman-walkthrough.html. 1. Invoke the -venkman command-line argument by typing mozilla -venkman to start Mozilla. You must start the debugger before the scripts it edits can be debugged. If you want to debug the file navigator.xul, for example, then Venkman must load before the main browser window. This limitation will either be fixed or worked around later. For the time being, you need to start the debugger first to debug browser chrome. Debugging JavaScript components is another example of when scripts must be loaded before the debugger is initialized. Because component registration occurs before command-line processing, when a component changes, it is reloaded at registration time and the debugger does not see it. Currently, the only way to work around it is to start the browser twice: once to re-register the modified component and once to debug it. 2. Launch a browser window and select "Navigator" from the debugger's Tasks menu. 3. Type break ContextMenu 357 in the debugger. The console command break is set and lists breakpoints. The first parameter is the filename that contains the JavaScript you want to break at. The second parameter is the line number. You don't need to specify the entire filename. In this example, we are setting a
breakpoint in the function called when the browser wants to create a context menu for web content. Or, you could select nsContextMenu.js from the Scripts View, locate line 357, and click in the left margin. Setting breakpoints in this way is equivalent to using the break command in the console. 4. Type break in the debugger. If you don't provide arguments to the break command, all breakpoints are listed. 5. Create a context menu in the Navigator window. A right-click in the content area creates a context menu. You should have hit the breakpoint you just set. The debugger should have displayed "Stopped for breakpoint," along with the filename, line number, and snippet source code where it stopped from. 6. Type step in the debugger. This command executes the line of JavaScript we're stopped on and stops again before the next line is executed. The step command is also available via the "Step Into" button on the toolbar and is bound to the F11 key. In addition to Step In, which executes a single line of JavaScript and stops, Step Over steps over a impending function call and returns control to the debugger when the call returns. Step Out executes until the current function call exits. At this point, you should be at line 359, this.onTextInput = this.isTargetATextBox(elem);. 7. Type props this in the debugger.
The props command lists an object's properties. The letters and dashes before the values are the flags for that value. The flags are enumerated in Figure B-3, previously shown. 8. Step one more time. 9. You should be in the isTargetATextBox function call now. 10. Type frame in the debugger. When used without arguments, the frame command shows you the source code for the current frame (with a few lines of context). 11. Type scope in the debugger. The scope command lists the current frame's local variables. In this case, there are two locals: node and attrib. The node property is an argument to the function, while attrib is a local variable. The scope is also visible in the Stack View. Open the [isTargetATextBox] frame and the scope node below it. 12. Type where in the debugger. The where command lists the current call stack. The frame command can be used to change the current frame to any frame listed here. For example, to view variables in the code that called isTargetATextBox, type frame 1, and scope. To return to the top frame, type frame 0. 13. Type eval window._content. The eval command evaluates arbitrary JavaScript in the current frame. Running the eval command on window._content itself isn't very useful, so you'll have to think of something more creative.
14. Type break. The break command, when used without arguments, lists the current breakpoints by index. 15. Type clear 0. The clear command clears breakpoints. In this example, we clear by breakpoint number, which we got from the break command in the previous step. 16. Type cont. The cont command continues execution. The context menu should pop up as it always does. B.6. MozillaTranslator Chapter 11 provides information about how to make a Mozilla application usable in many different languages. Localizing an application can be simple if your application is small. For large applications, though, localizing can be a long and complicated process. Fortunately, interested and enthusiastic developers created a tool that makes this process easier. MozillaTranslator is a program written in Java that reads in a package, provides an interface for changing the strings, and when finished, repackages the files for distribution. It is sophisticated enough to read JAR archives and output cross-platform installers (XPI). This type of solution is ideal for nontechnical people who translate the interface strings. MozillaTranslator is more than just a program for inputting translated strings. The web site (http://www.MozillaTranslator.org/) has resources
for setting up projects, uploading language packs, and finding the latest news on localization issues among other features. To get to the point at which you can input your translated strings, you need to take some introductory steps. After downloading and installing MozillaTranslator, follow these steps: 1. Select File > Manage Products. 2. Press Add in the dialog to add a package. 3. In the window that comes up, give the project a label (for your own use) and point to the chrome\en-US.jar file within your Mozilla build (replace the path with your own Mozilla application locale path). 4. Exit the dialog. 5. Select File > Update Product. 6. Select Edit > Chrome View once the update has finished. You should see the component structure shown in Figure B-4. You can then choose fields in which to view the chrome view window. Figure B-4. Chrome view in MozillaTranslator
At this point, you can edit the text straight from the chrome view. Another option is to bring up an edit window for a selected phrase, which supplies all possible editable fields in one window. An advanced search feature exists if you look for a piece of text in multiple files. When your strings are all done, packaging and preparing your language pack for distribution is as straightforward as selecting the Export > Jar File/XPI Install from the menus.
MozillaTranslator has the adaptability to handle any application locale, once you point it at the correct resources. Make sure that your files are packaged in the correct format -- namely, a JAR file. MozillaTranslator can handle all localizable resources: DTDs, string bundles, HTML, and RDF files. B.7. Missing Parts The tools highlighted so far are just some of the pieces needed to form a full- featured Mozilla development environment. Currently, several different areas of the application creation process would benefit greatly from a dedicated development tool. Some of the different types of needed tools are listed below. B.7.1. Visual XUL Editors XUL is a simple markup language that is similar to HTML. Some people prefer to create HTML code by hand, but others use programs that generate HTML code for them by using a simple point-and-click interface. The creation of a user-friendly XUL editing program would greatly simplify the creation of Mozilla applications and would allow many more people to start their own development projects. So far, there have been at least a couple of attempts to create such a tool. A few projects, such as Vixen (http://www.mozilla.org/projects/vixen/) and XULMaker (http://xulmaker.mozdev.org), have started to create a visual XUL editor. So far, however, there isn't a tool that allows someone to quickly create a user interface without creating XUL and CSS code by hand. B.7.2. Toolkits and Libraries Mozilla applications currently have a lot of duplication due to a lack of standard libraries and toolkits. Different types of applications still need to do
very similar things, so having common programming routines and interface widgets would greatly reduce the amount of time different developers spend recreating frequently needed parts of an application. In this book, we discussed the JSLib project (http://jslib.mozdev.org), which is trying to create a repository of versatile functions that any Mozilla application can reuse. For a project like this to work, however, it needs to be widely available and accepted by the developer community. To ensure its wide availability, these common libraries and toolkits need to become a core part of the standard Mozilla development tools. B.7.3. Integrating the Pieces Popular development environments like Microsoft's Visual Studio bring together a cohesive set of tools; they provide the tool framework in which much of the setup, code generation, directory structure, linking, and other drudgery is handled automatically. When used together, the tools described in this appendix can make your application development process easier. However, currently, all of these tools are located in different places and none of them interact with one another to provide a seamless development framework. Even when all the tools do become available, it will be necessary to integrate each of these together to create a single development environment for Mozilla application builders. This single tool will allow you to create the shell of an application easily and fill it with XUL, CSS, JavaScript, and all other parts of a Mozilla application that can then be packaged easily when you are done.