Tài liệu Appendix B. Development Tools- P2 pptx

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

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