blogjava-凯发k8网页登录

很是失望！随便说几条

一、arcgis server的进一步推广

自从9.0推出arcgis server我就感觉不妙。那时rob的  在国内正是火热，关于类似ejb的远程调用组件模型都值得我们思考。但esri却把宝压在这上面。

不但进一步完善com恶心的组件模型，还通过java-com桥，.net对com的向下兼容，整合出了arcgis server。

增加的开发难度一会在说。”循证框架“的选择权利也不给我们了吗？sde/soc/som/webserver 我都装在一台机器上，还是远程访问，够郁闷。系统/平台的分层不一定都要物理分离吧！ 

二、关于开发平台和操作系统平台

     .net/j2ee 的比较会带来太多的争论。具我了解esri对于java/.net开发是两个项目组。所以公司的侧重，开发的难易程度很是明显。当然底层组件的开发更重要。

      据悉esri gis软件最早是在unix系统下运行。不知道什么时候靠拢到window了。估计ms资组esri了 。就arcgis server 最先发布的是window平台下的。然后才是linux/solaris。。。别的不敢说，arcims9.1在 window/solaris/ibm aix的表现相差很多。当然是window支持的最好。

    虽然我喜欢.net的简单、开发效率。但我更相信大的企业应用是unix的天下。也就是j2ee是首选。arcgis server /arcims虽然官方支持多了平台，但是让我选择的话，为了让自己能睡着觉，我会先给客户选择window 2003。真是悲哀，客户花100万买的ibm p570/aix 居然让在那躺的睡觉。

     esri的做法让我很是不爽。

三、esri烦乱的产品线

    作为gis界”老大“，让人琢磨不透的复杂的产品线，让国内gis行业不能很好的发展，把门槛提的这么老高，到底是为了多卖点钱，随意分割产品呢？还是要故作深沉呢？ 首推arc engine,卖老贵，还没什么东西还有gis portal/adf/webservice支持....什么gs玩意？把gis这部分做好就让人满意了，还老跟着it潮流，可怜我们这帮gis程序员。

可能这也不能怪美国老，可能他们用的不错，但esri中国也给我们过滤一下啊。

四、技术选择

 esri是个没有创新的公司，只能跟着规范走的弱弱。

1、应用iframe/frame无刷新的提交数据是什么时候提出了，可能这方面arcims 的htmlview算早了吧！看看现在的ajax，官方文档只在9.2里出现过。但ajax还没出现，无刷新的技术当在javaeye讨论的时候，我这个新手就早在htmlview见识过。我想表达的是 为什么在我接触的arcims3.0/4.0/9.0 htmlview模板 丝毫没有变化过。这么好的思想n年都没有进步，还有模板例子中那些恶心，难懂的javascript代码？

 2、顺着ajax说下去。jsf/asp.net 这类 mvc框架天生不适合ajax的应用，而webgis天生就是ajax应用。 为什么选择这么恶心的官方标准。随便搜索一下ms ajax

 人家ms用ajax有atlas，

  sun也不在jsf上搞ajax。 顺便在这推荐一下 dojo 。

esri不能这样落伍了，为什么jsf还没有正式发布的时候，你的arcgis server adf for java 就选择的jsf。为什么那时不关注一下ms的atlas。 而还要自己写那些恶心的javascript代码， 用服务器端语言封装javascript。 我们是跟着你走，你跟这 sun/ms 走。

难道不知道 sun 提出规范/标准基本都是吗？强烈建议大家看 without ejb。

不知道跟ms合作的公司一般都会倒闭吗？

五、谁能给我解释ao如何在浏览器调用？

题目有些问题。

arcgis server 最想解决的问题是 让ao对象可以用浏览器调用。而不是象在arcims中，都是通过人可以识别的xml来描述。而是通过远程对象访问。

 到底是二进制远程对象访问好呢？还是象webservice 的xml协议好？我没能力说，但就开发难度，”性能“来说，arcims比arcgis server强很多。

所以arcims能解决的问题，没必要arcgis server。小道消息，arcims还有两年的生命力。

 关于arcgis server能实现的功能我们很想与人讨论。谁有兴趣可留言。

 我们可以从这个角度考虑。 arcmap是ao的实现。试问你arcmap的功能用了多少？没多少吧！因为很多人认为mapinfo比arcmap好用多了。　ao庞大的类库你熟悉吗？谁敢说熟悉，赶快通知我，我去拜师！

既然在桌面环境下，我们也没用ao的多少功能。更不用说我们二次开发商的客户了。所以我说：把ao搬到服务器端意义不大。

当然不是没意义，就象without ejb中说的。我们并不是在j2ee中不用ejb，但至少90%的j2ee项目不需要ejb，但我们却用了。

我现在就怕，arcgis server的宣传把国内那些所谓的“方案撰写者”迷失了。

前天和一朋友聊天，他说arcgis server可以实现严谨的浏览器采集（可能只拓扑关系，图形校验等）。但浏览器上的绘图限制已经让ao数据编辑没什么意义了。还是用arcsde for　java api.(不知道.net用户怎么办，用c的api?)

六、后记

一气呵成，大家看着开心一下就好。

prototype.js中用了大量的apply和call函数，不注意会造成理解偏差。
官方解释：应用某一对象的一个方法，用另一个对象替换当前对象。
apply与call的区别是第二个参数不同。apply是  数组或者arguments 对象。而call是逗号隔开的任何类型。

apply,call方法最让人混淆的地方也是apply,call的特色。但最好不要滥用。
能改变调用函数的对象。如下例，函数中用到this关键字，这时候this代表的是apply,call函数的第一个参数。

2、关于闭包
prototype.js在class.create,bind等中用到javascript的闭包特色。但整体上prototype.js对于强大的闭包特性用的不多。大家可以参阅我翻译的。
3、让我比较反感的两个方法
（1）
var class = {
  create: function() {
    return function() {
      this.initialize.apply(this, arguments);
    }
  }
}
很讨厌用别的语言的风格来写javascript。用这个方法构造自定义类  并没有觉得有多方便，减少代码行数，只会让人难理解，多定义一个initialize方法。
其实讨厌这条有些牵强，不过修改object的原型对象就有点过分了。
（2）object.prototype.extend
  先不过你取个extend的名字会让熟悉java的人引起的歧义。修改object的prototype就说不过去了。不知道作者是怎么考虑的。当你for in循环对象是，麻烦就来了。可能有人会问你for in干吗。 我一个项目中既用了dwr,也用了prototype.js，dwr返回的javascript对象都多了个exetend属性，还得特殊处理。
  以前我比较过，现在我明白个道理。对于javascript这种没有静态类型检查，语法宽松的语言来讲，如果你选择了某个js类库，那你也必须适应作者写javascript的风格。prototype.js的作者对extend的使用炉火纯青，如果我们不当它只是个属性拷贝的函数的话，多读读prototype.js的代码是好的。
4、关于函数的绑定
  类库提供了function.prototype.bind  function.prototype.bindaseventlistener两个方法。首先我们从概念上解释一个这两个方法。
任何一个函数都可以调用这两个方法；参数的是javascript对象或网页上元素对象；返回类型是个函数对象。
本来我就是个函数，返回还是函数，到这两个函数有什么不同呢。看实现代码，关键还是apply\call函数的代码。其实这里只是转化了一下方法调用的对象。

test

这是 上举的例子，个人感觉没什么意思，反而让我对bind,bindaseventlistener有些反感。（javascript就是这样，明明大家都知道的语法，但写出来的代码差别确很大）
看下面代码：

test

从上面代码可以看出bind/bindaseventlistener只是包装了一下apply/call方法，改变方法的调用对象。如例子，你可以把obj.getname方法转化成任何对象调用，并且把方法让表单元素触发。（bind和bindaseventlistener之间只是返回函数的参数不同）
这两个方法也可以用在对象之间的方法重用，实现类似继承方法的概念。看以下代码，其实是比较无聊的。

我从来没读过prototype.js的扩展项目代码，也不知道bind..的最佳实践，一起挖掘吧。但你绝对不要把bind/bindaseventlistener从绑定的词义上来理解，可能会让你更加迷惑。从apply/call理解本质。应用某一对象的一个方法，用另一个对象替换当前对象。

5、关于事件的注册

test

执行上面代码，你就能明白event.observe与bind/bindaseventlistener之间的区别：
（１） 显然event.observe有限制，只能处理简单的函数，并函数中不能有this之类的东西。
（２）event.observe内部用到addeventlistener／attachevent。能把多个函数加到一个触发事件（window.onload）。bind是覆盖。

6、关于事件监听最佳实践
很显然prototype.js提供的事件注册方法不是很完善。那看看dojo的时间注册吧（），更加复杂，估计很多人像我一样，对于dojo暂时持观望态度。
如果你看过的前篇关于闭包的介绍，可能见过以下代码。
看以下代码前我想表述一个观点，任何网页中元素，浏览器都会为你创建一个对象（）。（我觉得）这些对象与你建立javascript对象区别是它们有事件监听，会响应鼠标键盘的事件。如果你用了以下代码，那么把事件监听代码很好的转化到你的javascript代码中。

function associateobjwithevent(obj, methodname){
    return (function(e){
        e = e||window.event;
        return obj[methodname](e, this);
    });
}
function dhtmlobject(elementid){
    var el = getelementwithid(elementid);
    if(el){
        el.onclick = associateobjwithevent(this, "doonclick");
        el.onmouseover = associateobjwithevent(this, "domouseover");
        el.onmouseout = associateobjwithevent(this, "domouseout");
    }
}
dhtmlobject.prototype.doonclick = function(event, element){
    ... // doonclick method body.
}
dhtmlobject.prototype.domouseover = function(event, element){
    ... // domouseover method body.
}
dhtmlobject.prototype.domouseout = function(event, element){
    ... // domouseout method body.
}

有时间我想用以上思想实现一个网页浮动框拖拉的代码（其实已经有很多了），待续........

引用：ajaxcn.org 链接。谢谢dlee
 

arcims应用服务器：管理虚拟服务器，地图服务（admin配置的），连接器请求线程管理等。连接器调用它，它在调用空间服务器。一个应用服务器可以连接多个空间服务器。
arcims 空间服务器：把矢量书生成图片，或做空间分析，查询等。arcims的核心。还好我们不要关注具体算法等。开源gis,mapxtreme,super map等也就这部分没arcims强。但空间服务器与别的组件的协议是arcxml。虽然arcxml规范比较全面，但这个高度的松散偶合也给 arcims的复杂开发带来些局限性。以后我会提到。
2、 arcxml的重要性
因为搞编程的人不是地理学专家、矢量数据结构专家、图象技术专家。至少不能共同关注这好些技术。所以arcxml规范的定义是极其重要的。也可以让外行人开发专业的程序。这叫好比vml.svg标签语言一样，如果你不懂数学算法，不可能画一个椭圆。
　　　　以前我也说过，如果你掌握了arcxml，那你就基本知道arcims能做什么，能实现什么功能。至于做的好坏，那看你的行业知识、编程能力了。
3、 introduction to arcxml
上面说了一堆废话，现在看看arcxml到底是什么。
arcxml 是为了与arcims空间服务器通信而定义的协议。而arcims空间服务器是arcims的核心，它把地图和数据打包成适当的格式，发送到它的客户端 （arcims应用服务器）。要懂arcxml,首先必须知道怎么样配置文件，建立arcims服务，请求和响应，以及怎么与空间服务器结合。
 
1、 建立一个axl为扩展名的配置文件。（xml格式）
2、 用 arcims administrator 建立并启动 arcims service
3、 接受请求
4、 响应请求

4、 arcims核心（arcims spatial）
  arcims 空间服务器是arcims的核心。arcims软件也可以分布式部署arcims spatial.关于详细部署可以看arcims安装文档。有时间我写篇专门讲讲。如果是正版软件，你可以让esri公司来干这个事。

（1） 传输时间：接器的选择会影响
（2） 排队时间：以多建立虚拟服务器来解决。
（3） 渲染时间：比较费事，可以分布式部署空间服务器来解决）
（4） 查询时间：数据库调优，arcsde调优。（有时间再讨论）
5、 servletconnector与javaconnector的区别

以前文章我也简单说了说。

用图表来分析。
servletconnector:
 
上 图表示了servlet连接器的结构。注意，用这种连接器，把从arcims返回的arcxml直接传递给了浏览器，浏览器用字符串拆分技术或dom技术 来解析这个复杂的xml串。（还好htmlview的模板提供了这些代码，不过用javascript拆分字符串，没用dom标准）
    每次请求的arcxml字符串是很大的，arcxml包含的有些信息对用户是没用的，所以在web服务器与浏览器之间，浪费了许多带宽，对于二次开发人员，难度也加大不少。
javaconnector:
 
使用javascnnector ，浏览器与web服务器之间传输的协议由二次开发人员定义，这可能会加大编程难度，但随着ajax技术的成熟，开源框架dwr,json等的完善，这部分工作会越来越简单。
但javaconnector 引来一个问题，它的map java对象不是线程安全的，而这个对象的初始化比较费时间。它和jdbc中的数据库连接差不多。针对这个对象写了个map池，从我们项目运行的情况看， 效果还不错。如果用javaconnector,对java编程需要一定的基础。
6、 业务的复杂度决定我们应该用哪种连接器
如 果你只是想简单的发布地图，htmlview就可以满足你的需求。如果有复杂的业务，gisporal定制，权限管理，那你用htmlview会让你面临 灾难。我选择javaconnector. using_activex_connector, using_netlink也有文档。 但你要做大型，高性能的webgis,j2ee必定是受选，unix，arcims在j2ee的积累，arcims很多程序使用java实现的。（另外 arcinfo最早是在unix命令行形式运行的）。
a、 java语言比javascript高级多了。htmlview大多数用javascritp实现。
b、 跨浏览器的支持。噩梦吧。
c、 ajax技术的成熟，客户端与服务器端交互容易多了。
d、 webgis无刷新更新数据是必须的，那必须下载足够多的数据。安全性是个问题。
e、 权限判断，业务定制等用javascript实现简直是噩梦。
   
7、 webgis开发人员的感想
开 发webgis系统，对程序员的要求太高了，可是工资水平一直很低，行业极其不成熟，国内也没什么发展前途，让我好多次有想法转行专门做j2ee去，但还 是坚持下来了。国内这帮搞gis的都是学院派出生，相对编程能力，计算机应用水平比较差，对it行业市场把握能力也较差，被别人抢的先机。现在以 google牵头各大搜索引擎都提供的 地图服务，另外国内 edushi等又有一批仿三维的地图服务出现，让我看到一思希望。做传统gis 的公司该收复失地的，毕竟我们是有优势的。

参考：

arcims性能优化和调整  许晓辉