使用Qt的WebKit非常简单，直接把QWebView控件拖放到界面中去即可，但是默认的QWebView在实现上有些缺憾，比如无法打开新窗口，无法下载文件，无法打印等。然而这些功能是一个浏览器所必备的功能，我们的CB/S企业应用系统也需要这些功能。要想让浏览器支撑这些功能，只能通过重写QWebView来完成。

    要想让自制的浏览器打开新窗口，需要重写QWebView的createWindow方法，见如下代码：（UtmpWebView即为QWebView的子类）

UtmpWebView* webView = new UtmpWebView;     QWebPage* newWeb = new QWebPage;     if(type == QWebPage::WebModalDialog)     {         webView->setWindowModality(Qt::ApplicationModal);     }     webView->setAttribute(Qt::WA_DeleteOnClose,true);     webView->setPage(newWeb);     webView->show();     return webView;

    然而，这只能应对a标签的target属性为_blank的新窗口链接，无法应对使用javascript通过window.open的方式打开新窗口的场景。要想满足这一点，必须在QWebView的构造函数里，更改一下浏览器的配置参数，代码如下：

QWebSettings* default_settings = QWebSettings::globalSettings(); default_settings->setAttribute(QWebSettings::JavascriptEnabled,true); default_settings->setAttribute(QWebSettings::JavascriptCanOpenWindows,true);

 

 

    我们经常在网页中通过javascript使用window.print的方式来调用打印机打印HTML页面，常见的浏览器都会支持这个功能，然而QWebView默认并不支持此功能，要想让我们定制的浏览器支持此功能必须为其做一个事件链接，代码如下：

connect(this->page(), SIGNAL(printRequested(QWebFrame*)),this,SLOT(customPrintRequested(QWebFrame*)));     this->page()->setForwardUnsupportedContent(true);

customPrintRequested槽的实现如下：

QPrinter* p = new QPrinter(QPrinter::HighResolution);     QPrintDialog printDialog(p, this);     printDialog.setWindowTitle("UTMP打印");     if(printDialog.exec() != QDialog::Accepted)     {         return;     }     frame->print(p);

 

 

    同样QWebView默认也不支持下载文件。所有的浏览器把请求的响应分为两类，一类是浏览器可以解析的（Html文本），另一类是浏览器无法解析的（文件），常见的浏览器遇到无法解析的文件，往往会下载到本地给用户使用，要想让QWebView支持下载，就必须截获浏览器的unsupportedContent信号，该信号所对应的槽的代码实现如下

ShellExecuteA(NULL, "open", reply->url().toString().toStdString().c_str(), "", "", SW_SHOW);

    注意，要想让上面的代码正确执行，必须在头文件中引入windows.h（这也体现出QT框架与NativeAPI能没有任何限制的轻松交互）。上面的代码是调用了系统默认的浏览器来完成下载。当然读者也可以考虑自己实现下载线程并提示下载进度、保存地址等。

 

 

    我们既然选择自己开发浏览器，那么浏览器一定能自如的让页面执行一些特殊脚本，页面也可以通过脚本让浏览器完成一些脚本无法完成的操作。此功能一般的浏览器都无法支撑，只有我们自定义的QWebView可以轻松实现。

    我们知道javascript在页面中执行都会用到window对象，比如，我们调用alert()方法时，其实是调用window.alert()方法，使用document对象时，其实是使用window.document对象，要想让浏览器能与页面脚本交互，我们必须让浏览器给页面的window对象注册一个子对象（window对象的属性）。

    遇到的第一个问题并不是如何注册此对象，而是在何时注册。由于在页面加载之初，window对象就已经初始化完成了，此时为其注册子对象已为时已晚，必须在其初始化之前为其注册，为此QWebView专门提供了javaScriptWindowObjectCleared信号，在刷新网页、打开新网页和加载嵌套的iframe页面时（window对象初始化时），此信号都会被触发。与此信号关联的槽，代码如下：

this->page()->mainFrame()->addToJavaScriptWindowObject("QtWinFrame", this);

如你所见，我们为window对象注册了一个名为QtWinFrame的对象。这就像浏览器为window对象注册document子对象一样，要想让页面脚本能调用浏览器核心的方法，必须为让浏览器核心提供相应的方法才行，由于我们在第二小节已经把窗口默认的标题栏和边框去掉了，所以必须通过页面javascript来关闭浏览器和最小化浏览器，假设我们在浏览器核心中实现的方法代码如下：

void UtmpWebView::SetFrameWindow(int flag) {     switch(flag)     {         case 0:             this->close();             break;         case 1:             this->showMinimized();             break; } }

在浏览器页面内，只要通过如下javascript代码，即可让浏览器核心执行相应的操作：

QtWinFrame.SetFrameWindow(1);QtWinFrame.SetFrameWindow(0);

相对于“脚本让浏览器执行工作”来说，“浏览器让脚本执行工作”就简单很多，只需要在浏览器中调用evaluateJavaScript方法即可，见如下代码：

this->page()->mainFrame()->evaluateJavaScript("testFun();");

注意：这有些类似于javascirpt中的eval()方法，如果前端框架中引入了ExtJs，最好不要直接使用此方法来调用ExtJs提供的函数，执行效率非常慢。可以先在页面上用普通的js函数包装一下ExtJs提供的函数，再来调用。

 

    调试javascript代码一直以来都是开发人员面临的老大难的问题，自从有了FireBug和谷歌浏览器自带的javascript调试器之后，这个问题得到了很大程度的解决，所以有个好的javascript调试器十分关键。QWebView也提供了相应的调试工具（我认为就是谷歌浏览器的javascript调试器，但未经验证。）。使浏览器核心打开调试器的代码如下：

QDialog* d = new QDialog(this,(Qt::WindowMinimizeButtonHint|Qt::WindowMaximizeButtonHint|Qt::WindowCloseButtonHint)); d->setAttribute(Qt::WA_DeleteOnClose, true); QWebInspector* wi = new QWebInspector(d); wi->setPage(this->page()); d->setLayout(new QVBoxLayout()); d->layout()->setMargin(0); d->layout()->addWidget(wi); d->show(); d->resize(600,350);

    由于我们在系统启动的时候，使用Qt::FramelessWindowHint属性禁用掉了窗口的标题栏和边框，所以在打开调试器子窗口的时候，要恢复该子窗口的标题栏和边框，为此我们多做了一些工作，读者也可以自己实现QDialog类型的父类，以应对更多子窗口业务。

 

    既然我们对浏览器有最大的控制权，那么我们就希望当浏览器完成指定工作时通知我们，好让我们做一些前期或后期的处理。最常见的工作莫过于浏览器发起请求了。我们知道浏览器解析一个网页的过程中，可能会发起多次请求，比如图片标签的src路径，iframe标签的src路径，js/css资源的路径等等。要想知道这些请求何时发起，何时终结需要重写QNetworkAccessManager，然后通过如下方式，让浏览器加载自定义的QNetworkAccessManager

QNetworkAccessManager *oldManager = webview->page->networkAccessManager(); MyNetworkAccessManager *newManager = new MyNetworkAccessManager(oldManager, this); webview->page->setNetworkAccessManager(newManager);

然后，我们可以在自定义的MyNetworkAccessManager类中重写createRequest(QNetworkAccessManager::Operation operation,const QNetworkRequest &request, QIODevice *device)方法，其中request参数，包含了原始请求的URL信息，此方法需要返回一个QNetworkReply对象，假设我们想改变原始请求的路径，可以按如下操作方式来完成

return QNetworkAccessManager::createRequest(operation, myrequest, device);

如你所见，我们用QNetworkAccessManager新建了一个请求（createRequest的返回值为QNetworkReply类型），该请求中myrequest实参的类型为QNetworkRequest，其他两个实参从原始方法中获得。

 

 

    一般我们使用ExtJs（官方地址：http://www.sencha.com/products/extjs/），都是把它部署在服务端，浏览器请求页面时，也会相应的加载ExtJs的资源以渲染界面，但由于ExtJs包含众多js文件和其他资源，通过网络来加载的话，一方面增加了服务器IO消耗，另一方面增加了网络延时，很多用户反应基于ExtJs的网络应用呈现速度慢，都是这两个原因导致的。

    现在我们开发自己的浏览器，就可以把Extjs库（不包含业务JS代码，因为业务JS代码易于变化，不适合当作资源放在客户端）当作资源放在客户端，对于一个客户端来说，体积越小越好，然而以ext4.2.1 gpl版为例，官方提供的压缩包里，有很多内容不适合打包到客户端中。比如：教程、文档、源码、示例等，读者可以自行将这些内容删掉，然后把精简后的ExtJs类库放到浏览器应用程序编译文件夹内（[appDirectory]\build-UTMP-Desktop_Qt_5_1_1_MinGW_32bit-Debug\debug）,这样Extjs类库就与我们的浏览器可执行程序在同一个目录下了，如果让浏览器使用Extjs类库的资源，还应该在此目录下创建一个静态文件，以引入同目录下的静态资源，代码如下：

<link href="ext-4.2.1.883/resources/Css/ext-all.css" rel="stylesheet" type="text/css" />     <script src="ext-4.2.1.883/ext-all-debug.js"></script>

当然，单单引入资源，还无法呈现ExtJs的绚丽界面，此时还需要引入一个服务器端的JS文件，此文件通过Extjs的类库加载机制，加载更多的业务JS，以达到实现特定业务逻辑的目的。我们在下一节中会详细介绍这些内容。

<script src="http://localhost:8080/UTMP/app.js"></script>

在QT中只需要通过本地路径加载这个静态页面即可，代码如下：

UtmpWebView w;     QDir dir(QDir::currentPath()); QUrl url = url.fromLocalFile(dir.path()+"/debug/index.html"); w.load(url);

    由此可见，保存在客户端的资源基本都是业务无关的、比较稳定的、不易变更的资源。保存在服务端的内容，都是与业务有关的，比较容易变更的内容，这种机制主要意图是保证了业务的可升级性。    

 

 

 

　1.OPOA模式

 

    使用Extjs的企业应用系统大多都是OPOA模式（One Page One Application），OPOA模式的WEB系统只有一个页面，在这个页面中会引入extjs的资源并通过js来渲染一个框架页面，然后根据用户的操作载入更多的js代码，来完成不同的业务。对于我们的系统来说这个页面就是放在客户端本地debug目录下的静态页面。这个页面引入了一个服务器端的js文件（http://localhost:8080/UTMP/app.js），通过此文件以及由此文件加载的其他js文件，我们渲染出了一个框架页面，见如下代码：

Ext.application({     name:'UTMP',     appFolder:'http://10.0.7.109:8080/UTMP/app',     controllers:["sys.index"],     views:["sys.menuTree","sys.titleBar","sys.contentTabPanel"],     launch:function(){             Ext.create('Ext.Viewport',{            layout:'border',            items:[                {xtype: 'menuTree'},                {xtype: 'titleBar'},                {xtype: 'contentTabPanel'}            ]         });     } });

如你所见，这是一个Extjs系统的开始（Ext.application），而且我们使用了Extjs的MVC模式（关于ExtJs的MVC模式的相关资料请参阅：http://docs.sencha.com/extjs/4.2.1/#!/guide/application_architecture），系统界面中包含三个视图：menuTree、titleBar和contentTabPanel。由于我们设计的浏览器没有标题栏，所以视图titleBar就是系统的标题栏，它包含了关闭、最小化按钮。

 

    Extjs有一套独特的模块加载机制，它可以通过js类的名称空间来加载相应的js代码文件，比如视图文件的名称空间是UTMP.sys.menuTree，ExtJs框架会从appFolder指定的路径下找sys目录下的menuTree.js文件。在普通的ExtJs项目中，appFolder属性并不用设定为绝对路径，只需要使用相对路径即可，但由于我们的项目的主页（静态页面）是放在客户端本地的，如果使用相对路径的话，ExtJs框架就会在客户端本地寻找相应的资源，然而我们的业务JS文件都是放在服务端的，所以势必会无法加载这些资源。

　3.定制AJAX请求基址

    模块加载机制可以通过设置appFolder基路径来解决，但是对于业务JS代码随处可见的AJAX请求该如何处理呢？确实，AJAX请求也会面临这种问题，而且更为突出。因为在ExtJs中对AJAX请求做了很多封装：proxy、store、request、load等，随处可见ajax的身影。幸而ExtJs是一个对象化程度较高的js类库，使得这个问题能很容易的解决。

    在ExtJs中所有Ajax请求都离不开Ext.data.Connection类的支撑，我们可以使用ExtJs提供的观察者模式来注册Ext.data.Connection类的beforerequest事件（这是一种侵入性较强的做法），这样所有的AJAX请求，不管是proxy发起的，还是request发起的，都逃不出我们的手心，具体实现代码如下：

Ext.util.Observable.observe(Ext.data.Connection,{     beforerequest: function(conn, options, eOpts){         options.url = "http://10.0.7.109:8080/UTMP/"+options.url;     } });

 

 

    在使用QTCreator开发基于QT的应用程序时，不管是debug编译还是release编译，都无法到编译目录下，通过双击exe程序来执行应用（会提示“无法启动此程序，因为计算机中丢失xxxx.dll....”的错误信息），之所以在IDE内能顺利执行，是因为IDE已经为程序执行创建好了环境，但倘若不解决此问题，就无法把应用程序分发给直接用户。

     要解决此问题只要把Qt类库提供的dll文件放在可执行程序的目录下或其所在目录的子目录下即可，在C:\Qt\Qt5.1.1\5.1.1\mingw48_32\bin目录下有Qt类库提供的大多数dll，这些dll名称以字母d结尾的是debug编译的应用程序所依赖的类库，不以字母d结尾的则是release编译的应用程序所需要的类库，除了此目录内的dll外，在C:\Qt\Qt5.1.1\5.1.1\mingw48_32\plugins目录下还有一些应用程序需要的dll类库。

    如此数量众多的dll，都需要打包到我们最终的安装程序中去吗？当然不用这么做。通过IDE执行我们的应用程序时，我们只需要通过processExplorer工具来查看应用程序进程所依赖的dll，即可判定哪些dll是需要打包到安装包中去的（大多数情况下可以这么做，如果是开发人员通过代码动态加载的类库，那么我相信你也会自行甄别的）。

    

    可能有的读者会问：“我可不可以把类库静态编译到exe中去呢？”当然可以，但是非常麻烦，你需要自己静态编译整个QT工程，还需要对IDE做出相应的调整（要编译QT的Webkit还需要做更多的工作），这是一项耗时、耗力还不一定能成功的工作，我不建议这么做。

    当我们找到应用程序依赖的所有dll后，我们就可以使用打包工具来制作应用程序的安装包，当然也可以自己开发安装包工具（可以参见我的博客：http://www.cnblogs.com/liulun/archive/2011/12/12/2284360.html）。

    国内外有很多不错的打包工具，我推荐使用inno setup（http://www.jrsoftware.org/），它支持编写脚本来控制安装过程，使用LZMA压缩算法来打包程序（压缩效率非常高，是7-zip使用的压缩算法），但它并不支持中文安装界面，目前社区有开发者提供了针对inno setup的中文语言包，使用起来也非常方便。