ActiveDirectoryのプロパティにページを追加する方法

前回からの続き

ActiveDirectoryのプロパティにページを差し込む方法がわかったので説明します。

ページは COM コンポーネントになっていて追加するには、専用のプログラムを作成しないといけません。。。
超面倒です。多様性を持たせるにはコレしかなかったのか、、、

サンプルプログラムをビルドする。

サンプルは、Microsoft SDKの中にありました。場所はここです。

C:\Program Files\Microsoft Platform SDK\Samples\NetDS\ADSI\samples\DSUI\userext\userproppage

VC6 でもビルドできますが、 mfc42ud.dll がないとか言われたら、こちらを参考にインストールしてください。

LINK : fatal error LNK1104: ファイル "mfc42ud.lib" を開けません。

http://up-beat.pos.to/linux/cdiary.cgi?year=2005&mon=5&no=7

また、最新のSDKを入れていると、なってデバッグビルドが失敗します。

adsiid.lib(guid.obj) : fatal error LNK1103: デバッグ情報が壊れています; モジュールを再コンパイルしてください

とりあえず、リリースビルドは動くのでwww これでいいことにしておきますwww

リリースビルドできましたか?
リリースビルドが成功すると、以下のディレクトリに、userproppage.dll ってファイルができます。

C:\Program Files\Microsoft Platform SDK\Samples\NetDS\ADSI\samples\DSUI\userext\userproppage\ReleaseU

このdllを windows 2003 server のテスト機にコピーしましょう。

COM登録

COMなので、regsvr32 で登録します。
この例だと、userproppage.dll を c:\ にコピーしました。

regsvr32 c:\userproppage.dll

遊び終わった後の登録解除はこんな感じです。

regsvr32 /u c:\userproppage.dll


AD登録への前準備

実は、これだけだと何にも変わりません。。。
ADの display specifier ってヤツに登録しないと呼び出されないようです。

登録する方法はいろいろあるみたいですが、 ADSI EDIT で登録してみます。

で、問題なのが、普通は ADSI EDIT なんてインストールしていないことです。
こいつは、windows 2003 server のインストールCDの中に入っているので、windows 2003 server の CD からインストールします。
#ネットから落とせればどんなに楽なことか。

CD-ROMの以下のフォルダに移動し SUPTOOLS.MSI を実行しインストールします

D:\SUPPORT\TOOLS

フルパスだと↓な感じ。コピペ用
D:\SUPPORT\TOOLS\SUPTOOLS.MSI

画面の流れに従ってインストールします。



インストールが終わったら、コマンドプロンプトで、呼び出してみます。

adsiedit.msc

起動しましたか?

ADSI EDITによるプロパティ画面の登録。

この項目は以下のサイトを参考にしています。
http://www.moe.am/index.php/2009/03/pictures-in-active-directory-users-and-computers/

起動したら、 以下の階層に移動します

Configuration → 
CN=Configuration.DC=rtitest.DC=local →
CN=DisplaySpecifier →
CN=411

参考にしたサイトでは、 CN=409(英語)に登録していますが、今回は CN=411(日本語) に登録します。

CN=411 の階層の中にいろいろと並んでいますが、 CN=user-Display に移動します。
こいつをダブルクリックするとプロパティが開きます。

CN=user-Displayプロパティの adminPropertyPages をダブルクリック。

そうすると、こんな感じにいろいろ表示されるので、↓のように入れて、追加を押します。

10,{69D967C6-AB39-47b7-8F00-410185C80F89}


追加されたので、OKで閉じます。

たぶん表記は、こんな感じです。

<number>,{CLSID}

number はタブの並び準とかかなぁ。とりあえず空いている 10 番目を選択。

CLSID は、サンプルプログラムだと、userproppage.cpp の CLSID_ProppageUser でしょうか。

編集が終わったら、ADSI EDIT を終了して、ADの管理を立ち上げて、適当なユーさせのプロパティを見てみてます。

確認

うん?
なにやら上のタブの配置が変わったような。

キター!!!

無事ページが追加されました。

いやーうまくいきました、、、しかし値をたった一つ増やすだけで何でこんなに面倒なことをしないといけないんだろう。。。

あとは、サンプルを改造して、自分が好きな画面を差し込めば、ADを好きなようにカスタムすることができますね!

cakephp等ってデザイナーに優しくなくない? デザイナーとプログラマーとの分業について

某所の古いphpを最新のphpに移植しなくてはいけない、、、、
いままでrtiオレオレフレームワークだったから、そろそろcakephpとかzendとか入れようかなと思って、いろいろ調べている。

今のところ、オレオレフレームワークでデザイナーとうまい具合に分業できていたので、
流行のフレームワークとかを使えばよりデザイナーと分業できるだろうと思ってフタをあけて絶望した。。。

こいつ等は全然デザイナーに優しくないと思う。

rtiフレームワークの紹介

まずは、rtiオレオレフレームワークの説明から。
MVCではなく、、、LC+V (ライブラリ、コントローラー兼モデルw+ビュー)な構成をとっている。
んで、パスに関していは↓な感じできわめてフラットな構成。

/lib/ライブラリ1
/lib/ライブラリ2
/モジュール/制御1.php
/モジュール/制御1_画面1.tpl
/モジュール/制御1_画面2.tpl
/モジュール/制御1_画面3.tpl
/モジュール/制御1_画面4.tpl
/モジュール/制御2.php
/モジュール/制御2_画面1.tpl
/モジュール/制御2_画面2.tpl
/モジュール/img/画像置き場

拡張子とディレクトリでアクセス制限している。
テンプレートは.tplという名前だけど、Smartyぢゃないよ。

すべてのパスは、 img/ 等のように、 相対パスで書く。 このモジュールをサーバのどこに配置しても動作するように心がける。そして何よりDreamWeaverでデザイナーが開いたときにちゃんと画面が見えるというのが最大の特徴だ。

VSセキュリティ

いや、、そこのあなた言いたいことはわかる。
不要なファイルを webroot 上に上げるなんて死んでしまえゴラァといいたいんだろう。
確かにそれはそーなんだけど、、、こいつらには、個人情報等が入っているわけではないからそこまでヒステリックになる必要もないかなぁと思うんよ。
#ログとかはwebrootより手前のアクセスできない領域だし、管理用のページはLANからしか見えない領域においている。

img/ とかと相対パスベースで書いているのでサーバのパスにアップロードしても問題なく動作するし、
何よりも、DreamWeaver で見たときにそのまま状況が再現できるっていうのが何より最大の理由だ。

デザイナーからしてみれば、DreamWeaverで見た状態で動作する画面が見えるっていうのが一番いいと思うんだ。
複雑な設定を、あーだこーだしないと、、果てはテストサーバにアップロードしてphpで動かさないと動作が確認できませんっていうのは、プログラマの勝手な理由だし、怠慢だと思うんだ。

そんな感じで、DreamWeaverで開いたらすべてがそのまま見える。
これがrtiのオレオレフレームワークのモットーなんだ。

cakephpVSデザイナー

んで、cakephpとかのフレームワークの配置を見ていくことにする。
cakephpのappの下はこんな感じになっていると思う。

controllers/モジュール1_controller.php
controllers/モジュール2_controller.php
views/モジュール1/画面1.ctp
views/モジュール1/画面2.ctp
views/モジュール2/画面1.ctp
views/モジュール2/画面2.ctp
views/layouts/
webroot/index.php 
webroot/img/画像
webroot/js/

views/モジュール1/画面1.ctp をDreamWeaverで開いたらどうなるか?
#拡張子 ctp問題はとりあえず解決済みとしておいておく。。。
画像は、別のパスにおいてあるので読むことができない。×マークでかけてしまう。
cssはどうなるか? css定義は views/layouts/ に入っているからDreamWeaverでは読むことはできない。
結果画面は、、、画像はかけてcssは読めていない超のっぺらぼうな画面が表示される。

なんてこった。
これでデザイナーにデザインしろというのかっ!
これはあまりにもひどくないかと思うわけよ。

画像を絶対パスで書けって?

何?画像を /img/a.jpg のように絶対パスで書けって?
そして、DreamWeaverでサイトルートを設定しろ。そうしたら見えるし、cssも設定で読み込ませることが出来だろうって?
そんなふうに /img/a.jpg のような絶対パスで書いてしまうと、ソフトウェアをウェブサーバのどこに配置しても動くという汎用性が失われてしまうぢゃないか!
そして、設定すれば見えるなんてプログラマーの身勝手な理由をデザイナーに押し付ける気かと。

ユーザが /モジュール/action/ とかで起動するんだから、相対パスだったらずれてしまうだろうボケっていう人もいると思うけど、HTMLには、baseタグがあるから、それでちゃんと補正を書いておけば問題なし!
baseタグってIE4/NN4から使えるから今世の中に出ているほとんどのブラウザで問題ないと思われる。
いまどきIE3 + windows98でネットしているヤツなんていないだろうしな。

何かIE7でバグがあるらしいけど、headの内側にちゃんとおいていれば問題なし。
http://www.microsoft.com/japan/windows/ie/ie7/releasenotes/beta2.mspx

AJAX時代にはDreamweaverは意味なしって?

次、AJAX時代だから Dreamweaverとか役に立たなくね?そんなことないよん、、、多分。
rtiフレームワークAJAXにも対応しています。。。一応。

話が脱線しちゃうんだけど、 rtiフレームワークは、HTMLにAJAXで貼り付けるHTMLって定義しておくと、フレームワークAJAXで切り出しを行ってくれます。

何に使うかというと、ニコ動のタグみたいなもんを思い描いてほしい。タグって編集モードに入った後で編集衆望ボタンを押すと元に戻るよね。元に戻す部分を切り抜いて元のHTMLにinnerなパッチ宛てているんだろうけど、あんな感じにパッチとして当てる部分を切り抜いてくれるんだ。これでデザイナーはAJAX用のHTMLの細切れをデザインする手間が一つ減るわけさ。

ファイルがたくさんあることに対して

ファイルたくさんあると探しにくくない?ファイルを一つのディレクトにたくさん置いていると速度が遅くならない?っていう意見もあると思う。俺は全然そんなことない。エクスプローラとかでも最初の一文字を入力すればそのファイルにジャンプするぢゃん。だからファイルが400個ぐらいあっても全然平気です。特に不便と思ったことはないです。ファイル名でソートするようにしているので、制御用のモジュール名と画面テンプレートが近くに並ぶのですごく便利です。cakeやzendのフレームワークみたいに contollerやviewを別フォルダにおいているほうがあっち行ったりこっちいたりしなくてはいけずに逆に面倒と感じています。慣れの問題はあるでしょうが、、、少なくとも私にはrtiフレームワークのフォルダ構成に不便を感じたことは一度もありません。
ディレクトリのファイル数ですが、近代のファイルシステムにおいて、1万ぐらいファイルがないとパフォーマンスにはそれほど影響しないと思います。ベンチを取ったわけではないので思うとしかいえないんですが、、、逆にファイル300個程度で影響が出るなら /usr/bin とかで大変なことになるわけですから、大丈夫ではないんでしょうか。

まとめ

つーわけで、rtiフレームワークのほうがcakephp等のフレームワークよりデザイナーに優しいフレームワークだと思うわけですよ。
でも、世の中はオープンなフレームワークとかでデザイナーと分業とか高々と歌っている。
そこがわからない。

他のデザイナーの人は、これで困っていないの?
プログラマーと問題なく分業できているの?

世の中、実は分業なんてしていない?

知り合いとか、周りの人を捕まえて聞いてみると、、、

  • cakephpは使っているけど、layout使うとDreamWeaverで開いたときに壊れるから使ってな。パスが変なのはプログラム書き換えて強引に直して使っている
  • デザイナーが作ってくれたHTMLをプログラマーがもらって後はプログラマーが直している。デザイナーからプログラマーへは一方通行で双方向の行き来はない
  • デザイナーがパワポで作った画面イメージをベースにプログラマーがHTML書いてます(涙)

とかあって、全然分業が進んでいないように思えないんですけど、、、、

納期ぎりぎりまでデザイナーとプログラマーが分業してクオリティアップな作業しているうちらが変なだけなのか、、、って思うんだよなぁ。。。

いやいや、もっとすごい方法があるに違いない。
世の中にあるもっと高度なデザイナーとプログラマーの分業のやり方をぜひ教えてください!!!

#rti フレームワークはそのうち、、、権利関係がクリアになったらw、NYSLで公開したいと思います。
#結構リライトしないといけないから来年ぐらいかなぁw、気長にお待ちください。