Selenium Source Analysis-webdriver (ii)

Recently more idle on a careful look at the source of selenium, because the main use of webdriver so focus on the webdriver work principle. In the previous blog has explained that Webdriver and the previous Selenium JS injection implementation is different, directly using the browser native support to operate the browser. So for different platforms, different browsers must rely on the native component of a particular browser to implement Webdriver API calls into the browser's native invoke.

In our new webdriver process, selenium first confirms that the browser's native component is available and has a version match. It then launches a set of Web service in the target browser, a Web service that uses selenium's own design-defined protocol, named the webdriver wire Protocol. The protocol is so powerful that you can almost manipulate the browser to do anything, including opening, closing, maximizing, minimizing, element positioning, element clicking, uploading files, and so on.

The Webdriver wire protocol is generic, meaning that either firefoxdriver or Chromedriver, a Web Service based on this protocol is started on a certain port after startup. For example, after the Firefoxdriver initialization succeeds, the default will start with http://localhost:7055, and Chromedriver is probably http://localhost:46350. Next, any API that we call Webdriver requires a comandexecutor to send a command that is actually an HTTP request to the Web Service on the listening port. In the body of our HTTP request, we will tell selenium what we want the browser to do next, in the JSON-formatted string specified in the Webdriver wire protocol.

Here the author initially drew a diagram to show the working principle of various webdriver:

As we can see, the Webdriver subclasses of different browsers need to rely on specific browser-native components, such as Firefox, which requires a add-on name called WEBDRIVER.XPI. and IE, you need to use a DLL file to convert the Web Service command for the browser native call. In addition, the Webdriver wire protocol is a set of restful Web service based on the figure. If you do not understand what is restful, you can refer to the author's other blog about rest (http://blog.csdn.net/ant_yan/article/details/7963517)

Details about the Webdriver wire protocol, such as what you want to know about what this Web service can do, read the Selenium official protocol document, and in Selenium's source code, We can find a httpcommandexecutor this class, which maintains a map<string, COMMANDINFO>, which is responsible for converting the simple string key, which represents the command, into the corresponding URL, Because the idea of rest is to treat all operations as a single state, each state corresponds to a URI. So when we send an HTTP request to this RESTful Web service with a specific URL, it resolves what needs to be done. Intercept a section of the source code as follows:

[Java]View Plaincopy

2. Nametourl = immutablemap.<string, Commandinfo>builder ()
4. . Put (New_session, post ("/session"))
6. . put (QUIT, delete ("/session/:sessionid"))
8. . put (Get_current_window_handle, GET ("/session/:sessionid/window_handle"))
10. . put (Get_window_handles, GET ("/session/:sessionid/window_handles"))
12. . Put (GET, post ("/session/:sessionid/url"))
16. //The Alert API is still experimental and should isn't be used.
18. . put (Get_alert, GET ("/session/:sessionid/alert"))
20. . Put (Dismiss_alert, post ("/session/:sessionid/dismiss_alert"))
22. . Put (Accept_alert, post ("/session/:sessionid/accept_alert"))
24. . put (Get_alert_text, GET ("/session/:sessionid/alert_text"))
26. . Put (Set_alert_value, post ("/session/:sessionid/alert_text"))

You can see that the actual sent URL is a relative path, the suffix is more/session/:sessionid start, which means that webdriver each launch browser will be assigned a separate SessionID, multithreading parallel to each other without conflict and interference. For example, one of our most commonly used webdriver api,getwebelement here will be converted to/session/:sessionid/element this URL, and then in the emitted HTTP request The body is enclosed with specific parameters such as by ID or CSS or XPath, and what are the respective values. After receiving and performing this operation, an HTTP response will also be returned. The content is also JSON, which returns various details of the found webelement, such as text, CSS selector, tag name, class name, and so on. Here is the code snippet that parses our HTTP response:

[Java]View Plaincopy

2. try {
4. Response = new Jsontobeanconverter (). Convert (response.   class, Responseastext);
6. } catch (ClassCastException e) {
8. if (responseastext ! = null && " ". Equals (Responseastext)) {
10. //The remote server has a died, but has already set some headers.
12. //Normally this occurs when the final window of the Firefox driver
14. //is closed on OS x. Return NULL, as the return value _should_ be
16. //being ignored.  This isn't an elegant solution.
18. return null;
20. }
22. throw New Webdriverexception ("cannot convert text to response:" + Responseastext, E);
24. } //...  

I believe summed up that here, should be the operating principle of webdriver should be clear! Actually quite admire this set of restful Web service design. Feel package Webdriver exposed public API can also be more friendly with a strong point, this time first summed up here, will continue to analyze selenium source code, continue to share!

Article Source: http://blog.csdn.net/ant_ren/article/details/7970793

Selenium Source Analysis-webdriver (ii)