Namespace を使用しているXML文書に対するXPath式

プログラミング

NameSpace を使用しているXML文書に対する XPath 式は注意が必要です。

XPath を取り扱うライブラリに対して、どのネームスペースを使用するか、予め登録する必要もありますが、それが NG であるシチュエーションもあります。

たとえば、以下のSpring のXML Schema に対して、XPath 式の指定を考えます。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<xsd:schema xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.springframework.org/schema/beans">

	<xsd:import namespace="http://www.w3.org/XML/1998/namespace" />

         ...

</xsd:schema>

ルート要素を指定する場合、namespace がなければ

/schema

となります。しかしネームスペースが使われていますので、上記式では要素を検索できません。

URI が http://www.w3.org/2001/XMLSchema となっており、xpath 式で ":" と "/" は特別な記号なので、以下では処理できません。

/http://www.w3.org/2001/XMLSchema:schema

以下の指定もNGです。xsd という接頭辞がどのネームスペースに所属するか解らないので。

/xsd:schema

xpath 式の関数を使用して指定することになります。

/*[local-name()='schema' and namespace-uri()='http://www.w3.org/2001/XMLSchema']

xpath 式が長くなるのが難点です。

ExtJS 3.1 で Ext.applyIf の動作が変わっています

プログラミング

ExtJS の Ext.applyIf の動作が、3.0 と 3.1 とで変わっています。

ソースコードを見ると一目了然です。

3.0

applyIf : function(o, c){
  if(o){
    for(var p in c){
      if(Ext.isEmpty(o[p])){ <-- ここが変わっている
        o[p] = c[p];
      }
    }
  }
  return o;
},

3.1

applyIf : function(o, c){
  if(o){
    for(var p in c){
      if(!Ext.isDefined(o[p])){ <-- ここが変わっている
        o[p] = c[p];
      }
    }
  }
  return o;
},

プロパティ値を上書きする判定条件が、isEmpty から isDefined に変わっています。
つまり 3.0 では nullや空文字列 の場合に上書きされていましたが、3.1 では上書きされません。

Ext.applyIf は クラスの継承の際によくつかわれる関数ですので、注意が必要です。

http://www.extjs.com/products/extjs/CHANGES_ext-3.1.0.htmlにも載っていない気が．．．

Spring Security Filterを動かさないパスを指定する

Spring Securityは、さまざまな処理をFilterで実現しています。

しかし画像やCSSファイルなど、Filter が働かなくて良いパスもあります。

そもそもweb.xml の設定で、Spring Scurity の Filter Chain に処理を渡さないように設定できれば良いのですが、web.xml ではフィルタの除外設定を記述できないので面倒な場合があります。

そういった場合にどうするか。

Spring Security の の設定で、filters="none" を指定します。
たとえば以下のように記述すると、/image や /css というパスでは、Spring Security の Filter Chain が動作しなくなります。

<http>
  <intercept-url pattern="/User/**"  access="ROLE_USER" />
  <intercept-url pattern="/css/**"   filters="none" />
  <intercept-url pattern="/image/**" filters="none" />
</http>

ExtJS 3.1 で Ext.applyIf の動作が変わっています

プログラミング

ExtJSの話。

cookie から Ext.state.Manager が Component の state 情報を読み込むのは、Component のオブジェクトを生成するタイミング。

Ext.Component のinitState()メソッドにおいて。このメソッドはprivate メソッド。

オブジェクト生成後、state 情報を上書きするようにプログラムを記述すると、cookie から読み込んだ情報は失われてしまう。つまりまるでcookie に state 情報は保存されていないかのように動作してしまう。

たとえば以下のような記述の仕方はまずい。

win = new Ext.Window( {
  layout: 'fit',
  closeAction: 'hide',
  plain: true,
  items: iframePanel,
  stateful: true,
  stateId: 'iframe'
});
win.height = 600;
win.width = 800;

Google Apps にて OpenID によるログインを有効にする方法

Google Apps にて、OpenID によるログインを有効にする方法。

ドメインの管理者にて、以下の手順で OpenID によるログインを有効にできます。

1. ドメインの設定 -> 全般 -> コントロールパネル にて、"拡張版 (アメリカ英語のみ) を選択

2. Advanced tools -> Federated Login using OpenID にて、"Allow users to sign in third party websites using OpenID" を選択

コントロールパネルの拡張版は、現在のバージョンのものより色々な設定があるので面白いです。

Google Docs と Google Sites

Google Docs はよくできていますが、あくまで Microsoft Officeのネット版／グループウェア版という位置づけでしょうか。作成したファイルを共有するという観点においては、面倒くさいです。

単にファイル共有という目的で使うならば、Google Sitesのほうが適当です。ファイルキャビネットテンプレートというものがありますが、これでは簡単にファイルのアップロード、アップロードしたファイルの一覧ができます。

ファイルの履歴機能も持っているので、SVNのような編集の競合を検知する機能はありませんが、簡単なバージョン管理は実現できます。

またGoogle ということで、検索機能が同時についてくるのもうれしいところです。

ファイルサーバ上でファイルの整理にフォルダを使っていた点については、ページが対応します。整理したい単位ごとにページを作成し、そのページ毎にファイルをアップロードしていく形になります。

共有という観点ではGoogle Sites自身にはサイトを共有する範囲の設定ができるので、会社単位で共有のものを１つ作り、そこにファイルを上げていけば会社レベルでのファイル共有が実現できます。
細かいページ単位での共有設定はできません。この辺はファイルサーバとの差になります。あとサイトの共有設定に注意しましょう。うっかりパブリックにしてしまうと、えらいことになります。