全部博文(230)
分类:
2010-07-10 22:50:29
To prove it, go to the Run command on your Start button and write the
following:
javascript: alert("hello world");
This should initiate whichever application is associated with the JavaScript protocol on your system, probably Internet Explorer, and execute the script. This is the same principle involved in . A bookmarklet "a tiny program (a JavaScript application) contained in a bookmark (the URL is a "javascript:" URL) which can be saved and used the same way you use normal bookmarks."
You can use the JavaScript protocol from other browsers such as Mozilla, as Mozilla does not start up Internet Explorer when someone writes the code above in its address bar. Mozilla will pass any APP that it does not handle natively to the proper system handler. As I showed above, you can even use the JavaScript protocol from the Run box under your Start menu.
What You Need |
Windows 98 or later with IE 4 or later, Wscript, , and a text editor. |
MSDN provides some about APPs, but be wary of what you read: You may come away with a misconception about what is required to achieve the most basic implementation of an APP under Windows. For example, implies that to write an APP one needs to implement certain interfaces, but APPs are actually very flexible. The basic implementation of an APP under Windows requires only that you make the proper entries in the registry for your protocol and that the handler for your protocol is a valid Windows .exe file. You can see an example at . The "note" protocol defined in that example opens Notepad, similar to the way the view-source:// protocol can be used to open the .htm source of an HTML file in Notepad. For example, try putting this in your browser: view-source:http://www.devx.com.
I doubt that Notepad implements or any related interfaces, as to do so it should be a COM implementation and found at the following registry address HKEY_CLASSES_ROOT\PROTOCOLS. Without these related interfaces, in the end all that happens is the protocol address is passed as a string via the command line to your application for analysis.
The W3C provides of addressing schemes, which you can use to search your system to see if these addressing schemes are implemented as APPs. Those that do more than just call over the command line should be found at the HKEY_CLASSES_ROOT\PROTOCOLS\Handler registry key.
There are many tools that allow you to dynamically load files via the
command line, and pass on command lines to files. One example is script
interpreters such as Wscript.exe. Here is the sample registry file,
which shows how to set a simple WScript as the handler for a protocol
called ws-proto.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\ws-proto]
@="\"URL: ws-proto Protocol\""
"URL Protocol"=""
[HKEY_CLASSES_ROOT\ws-proto\shell]
[HKEY_CLASSES_ROOT\ws-proto\shell\open]
[HKEY_CLASSES_ROOT\ws-proto\shell\open\command]
@="wscript.exe c:\\wsproto.js %1"
Here is the protocol that handles the WScript. (Both the registry file
and the protocol handler are available in the code download for this
article—see left column).
WScript.Echo(WScript.Arguments(0));
| |
A JavaScript Alternative: Rebol
Most protocol implementations are done with a particular goal in mind,
however there are certain protocols, such as the JavaScript protocol,
that are designed to extend the functionality of the system as a whole,
and the browser in particular.
It is this latter type that I will build in this article, using the JavaScript protocol as a model. The JavaScript protocol allows you to transmit JavaScript code that will then be evaluated within the browser. This means that the objects available to the protocol are the objects exposed by the browser. In our earlier example, the alert() functioned because alert() is supported in the browser environment.
| |
Why Rebol? Because Rebol is particularly good at handling protocols. By implementing a dynamic evaluating protocol in Rebol, I can very easily add functionality to interact with ftp, smtp, http, etc. (These protocols are easily accessible from Rebol using Rebol's one-liner scripts, e.g. one line of code to read a URL and write the output to a local file.) Rebol can interact with any protocol that can be called via bookmarklet-type behavior, from a link on a web page, from writing in the address bar, from shortcuts, or from most any programming language/environment in the Windows system.
| |
It's time to implement the Rebol script. There are links at various points to the , which provides definitions of built-in Rebol functions to help you along. In the code download for this article there is a registry file called rebsettings.reg, which sets the reb protocol to be evaluated using a script called reb.r. Reb.r is the protocol handler that the registry files point at (see ). Install Rebol in the default installation folder c:\rebol\view. Be advised that the Rebol installation program asks you for information such as your email address, email server etc., which it needs to send and receive mail and for the examples to work.
Once Rebol is installed, you should merge the accompanying .reg file and also install the files in the downloadable sample code (see link in left column) to the c:\rebol\view directory. When you've done that, open the example.html file in your default browser. shows the contents of the example.html file.
This file has three simple JavaScript functions called callreb(),browseloc(), and insertPrompt().
The first link in the HTML page is:
read a local file and write result to new local file
Everything past the reb:// is legal Rebol code. And it does exactly what the link text tells you: It reads a local file, contained in the code download called oldfile.txt and writes a local file called newfile.txt. (Note that the parameters are intentionally opposite their function—this is because of the evaluation order of Rebol syntax). The % before the file names tells Rebol that these are in fact files. When you click on the link you should see something similar to :
The popup is generated by Rebol's built-in security (more information on controlling Rebol security settings). When you click Yes, reb.r loads (see ).
Pressing Do causes the Rebol interpreter to evaluate the text contained in the
1 + 5
1 + 5 is valid Rebol code so if you press Do the text field should read
6. If you wrote the following in the text area:
1 + 5 > 7
the text field would display false. If your wrote 1 + 5 > 4 it would
display true. And if you wrote:
(1 + 5) * 7 + 6
the text field would display 48. You can find more information about Rebol Math at .
Branching Out
Now that you've created one link to see how it works you can quickly
test others. The next link, 'browse this page,' is a JavaScript function
that builds a reb:// link where the protocol
body causes a browser to browse to a URL (the value of location.href).
For local files the location.href will be a file:///
link—the location of your HTML document; for files on the Web,
the location.href is the location of the file
over http. In either case, the browse protocol opens the default
protocol handler for either file:/// or http:// (probably Internet Explorer in the first case,
and your default browser in the second). So, for example, if you happen
to be viewing a page in your non-default browser you can switch and
view it in your default browser by using Rebol's browse function. Simply
add reb://browse in front of the http URL in
the address bar.
The next link (another Rebol one-liner) is similar to the first one; it reads the address http://www.devx.com and writes it to a local file called text.htm.
You might want to steel yourself before clicking on the third link, it can be a shock if you're unprepared. It uses the to execute a file found at an http address. (This can also be used to execute a file found at an ftp address.) The particular file being executed is called websplitter.r and can be found at . You can find the text of the file at . Clicking this link or pushing the Do button from the sample form opens the Rebol shell, gets an HTML file from Rebol.com, and strips out all the tags. It prints the tags minus the text content to the shell and then the text content minus tags.
The next link sets the value of two Rebol variables, string and webpage,
to 'microsoft' and the content at respectively.
If the string 'microsoft' is found anywhere on the Web page, then the
shell opens and the code prints the contents of the Web page to it:
search yahoo front page for instances of "microsoft"
Rebol has numerous ways to deal with strings and putting them in curly brackets—as shown above with Microsoft—works from many different interfaces.
The following are examples of building a reb:
link with insertPrompt() using user input:
send an email
send a page
So clicking on one of the links displays the prompt: "Please write your email address here." When you do the code calls the reb:// protocol and you will either receive an e-mail with the text "hello from reb protocol" in the body, or the HTML of the page as text.
Finally, to write a local file containing the contents of a file located
on an ftp site, you can use the following link:
test ftp
That's enough simple examples. Here's a brief explanation of the sample reb.r code (see ). First, reb.ra parses the input to a separate executable script from the protocol body. The following two lines perform the separation:
argsstring: to-string system/script/args
parsestring: remove/part argsstring 6
System/script is an object that applies to the script argument passed in (think of it as the Rebol DOM). One subsidiary object of system/script is args, which contains the command line arguments. The word argsstring turns this object into a string value. The word parsestring then removes the first six characters of the argsstring string. is a Rebol function.
Author's Note: Rebol calls these variables "words." In Rebol, a word may or may not be a variable, depending on how it is used. |
Clean Up
Next there's a little problem with command arguments that originate in
browser address bars: The URL ends with a forward slash (/). The slash
can cause some real problems, so you need to remove it, using this code:
if #"/" = last parsestring [
remove back tail parsestring
]
This checks if the last of parsestring is the character "/"; if so, it executes the code inside the square brackets, called a block in Rebol. It also removes the last character of parsestring by going to the end and moving one character backward. One of the goals of Rebol's design was to make it more like a natural language, which I think has succeeded, although at some points the grammatical methods of verb inflexion quite maddening can be. ;)
Next I set the value of the word filename to be %reb-protoLog.txt. This is the name of the log file where the script saves the protocol body when you save.
Now a look at the code that creates the form. As I stated earlier Rebol/View includes a dialect for creating GUIs. (Read more about the .) You call this dialect with the code:
view layout[
]
Everything within the square brackets gets evaluated as being code in the View dialect.
The next three lines should be pretty clear:
vh2 "result:"
f1: area parsestring return
f2: field
The code creates a headline (think of it as being analogous to the h2 tag in HTML) with the text "result:" beneath that is an area, analogous to an HTML
Next:
button "Save"[write/append filename join newline join now join ":" join newline
join f1/text join newline
"_________________________"]
The form has a button with the text value "Save." When you click on it the Rebol code in the block associated with the button gets evaluated. This code could have been written in a cleaner manner, but doing so might have been more confusing for someone unfamiliar with Rebol. Basically all the preceding code does is write or append a text value to the file %reb-protoLog.txt that I associated with the word filename earlier. The code builds up the text value written to the file by concatenating other values together. Concatenation is handled via the word .
The Save button code concatenates linefeeds/carriage returns (made by
the word newline), the present date/time (made by the word now) followed
by a colon followed by the text in the area F1, which, will be the same
as the text passed in the protocol body if the user does not edit it
first. Finally, the code appends another newline and a line
"________________________" to break up various log entries.
Next:
button "Do" [ clear f2/text
err: error? try[returnstring: to-string do f1/text]
either err = true[
append f2/text "No string output returned"
show f2][append f2/text returnstring
show f2]
]
Another button with the text "Do," causes the application to execute code sent to it. The first thing the button code does is clear any text already in the F2 field. This is necessary in case a user edits the value of F1 several times, as in the calculator examples. The word err evaluates f1/text as well as checking if there is an error. By breaking the preceding code down you can get a better feel for the way Rebol evaluates code:
do f1/text
This code evaluates the string in the F1 area as Rebol code. The word to-string before the 'do' line (see above) attempts to turn the result of that evaluation into a string ('do' does not return a value unless the operation it evaluates returns a value). This whole process is associated with a word— returnstring—wrapped within a simple error-checking process.
Next it checks to see if an error occurred with the line:
either err = true
If an error occured, then Rebol executes the first block, right next to the true, if no error occurred then Rebol evaluates the second block. The first block writes "No string output returned" to F2. If the second block gets evaluated then the process of evaluating whatever was in F1 did return a value, and the code writes that value to F2 using the word holding that value—returnstring.
button "quit" [quit]
This last bit of code should be self-explanatory. When a user clicks on the quit button the code inside the block evaluates the function.
If this article inspires you to learn more about Rebol, please check out the related resources in the left column. is an advanced article about writing protocols in Rebol. The techniques presented there, combined with those presented here, will let you implement many protocols that are still missing in the Windows system with relative ease.
Author's Note: The author wishes to thank Gabrielle Santilli, Gregg Irwin, Carl Read, and others from the for their help. |