MTOS版 CustomFieldsの作成について
しんち
アークウェブ（http://ww.ark-web.jp/）という会社でエンジニアやってまして、先日「A-Form」というMT4.x/MTOS向
けプラグインの開発、リリースを行いました（http://www.ark-web.jp/movabletype/）。
「A-Form」はドラッグ＆ドロップによる簡単操作でフォームを作成し、MTのブログやウェブページに埋め込めるようにしたものです。
それで、先々週(4/5（土）)に「MT4LP5（http://mt4lp5.cssnite.jp/）」に伺わせて頂いたところ、「「A-
Form」の仕組みを利用してMTOS版のCustomFields作れるよ」といったフィードバックを何人かの方に言っていただきまして、上司も会社
の時間を使って行うことに許可してくれたので（笑）、やろうと思っています。
それで、
- できれば、社外のエンジニアの方達と連携して開発する
- 作ったプラグインはMTOSのオープンソースコミュニティに提供して貢献
- 開発はオープンに
といった形でやりたいなと考えてます。
ただ、既に野田さん、小川さん、蒲生さん、丹羽さんには直接メールでお話させていただいてまして、その折に野田さんから、
- MT製品版とMTOSの差が実質CustomFieldsのみである状況でCustomFieldsを出してしまうのはSixApartにとって
どうなのか？
- SixApartがCustomFieldsをMTOSにも提供しちゃったら？
- MTOSで開発するなら、まだ存在しない機能で、かつSixApartが買いとりたくなるような機能がよいのでは？
というフィードバックも頂いていまして、確かに一理あるなと感じているところです。
単純にCustomFieldsのコピーをMTOSに提供するのでは作るのもつまらないので、作るならMT4.xのCustomFieldsの単純な模
倣じゃなくて、より使いやすい工夫や機能を盛り込んだ形にする必要があるかなーと思っています。
たとえば、
- A-Formのようなドラッグ＆ドロップのUIを提供する
- バックエンドとフロントエンドを分けたアーキテクチャにして、フロントエンドでCustomFieldsのような仕組みを作ったり、A-Form
のような仕組みを作るような様々なインタフェースにつなぎこめる拡張性を提供する（こちらは小川さんの案）
などまで狙っていくのがいいかなと思っています。
ただし、これでもいぜん
- MT製品版とMTOSの差が実質CustomFieldsのみである状況でCustomFieldsを出してしまうのはSixApartにとって
どうなのか？
の懸念は残ってしまいます。
このスレッドでは、プラグインを作っていくとして具体的にどういった機能、アーキテクチャにしていくか、そもそも野田さんが仰るように
CustomFieldsの機能を「今」提供することは是なのかを議論したいなと思っています。
しんち個人の現在の意見を表明しておきますと、
- Six Apartには儲けて頂きたく、CustomFieldsしか実質的な差がない状態で、MTOS版CustomFieldsを出してしま
うことには迷いがある
- 同時に、MTOSユーザに便利な機能は（CustomFieldsでなくても）積極的に提供していきたいし、MTOSコミュニティが活発になり
ユーザベースが増やすことができればSix Apartの利益にもつながるとも思う
- MTOSでCustomFields（に類するもの）を提供することは、予算とリテラシーの限られていることが多いNPOやNGOがWebを活用
できる可能性を広げていけると思うので、こうした方達に対してもっと貢献していきたい
といったところで、正直迷っています＾＾；
ただ、CustomFieldsという形ではなくても、MTOSのユーザコミュニティ、SixApart、およびMTOSビジネスを考えている立場の
方、みんながそれぞれに喜べる形を作っていけたらなと思っています。その点、Six Apartの中の人のご意見聞けたらうれしいんですが＾＾
皆さんのご意見を聞かせていただけるとうれしいです。
以上、よろしくお願いします。
しんち
自己レス
> 単純にCustomFieldsのコピーをMTOSに提供するのでは作るのもつまらないので、作るならMT4.xのCustomFieldsの単純な模
> 倣じゃなくて、より使いやすい工夫や機能を盛り込んだ形にする必要があるかなーと思っています。
>
> たとえば、
>
> - A-Formのようなドラッグ＆ドロップのUIを提供する
> - バックエンドとフロントエンドを分けたアーキテクチャにして、フロントエンドでCustomFieldsのような仕組みを作ったり、A-Form
> のような仕組みを作るような様々なインタフェースにつなぎこめる拡張性を提供する（こちらは小川さんの案）
>
> などまで狙っていくのがいいかなと思っています。
- Ruby on Railsのscaffloldのようにモデル定義からコマンドラインでのコマンド一発でモデルの新規作成・更新画面、詳細画
面、一覧画面、削除機能を提供する仕組みを作る
- ↑の詳細画面、一覧画面のViewはサブのpluginを開発することで、独自Viewに切り替え可能な作りにする。
CustomFieldsのようにリテラシーが低いユーザでも使える仕組みではないですが、MTOSをCMSとして利用することを考える時、制作する人
にとっては便利かなと。
蒲生トシヒロ
蒲生です。
僕は、昨晩入稿しましたが、MTOSでこそ、ポータルサイトを作るべきと文章を書きました。
健全なWebマーケットの育成を考えると、5万円のライセンス代を払いたくないという人の手助けにしたくないなと…。
GPLライセンスで配布されれば使えるのなら、有償でいいと思います。
CustomFieldsを凌ぐ機能にするなら、GPLライセンスで配布して商用は有償としてMTより高い値段で販売すれば、
＃このあたり怪しいです、商用は有償で、非商用は無償という販売方法ができたのか詳しく知りません。
＃ボランタリー団体からお金をとることは避けたいですね。
無償で配布するなら、複数のテンプレートを登録できて、入力サポートにつながるようなものだといいなと。
要はテンプレート作成モジュール。
僕はFCKeditorでやってますが、これのもっとスマートなものがあるといいなと思います。
http://www.dakiny.com//archives/movable-type/movable_type_41mtpluginfckeditorver21/
HTMLテンプレートを登録して、引き出すだけのものなら
CustomFieldsの領域を侵すものではないでしょう。
以上、思いつきです。
蒲生トシヒロ（GAMO, Toshihiro）
〒503-0808 大垣市三塚町996番地1 アーバン21 108号室
有限会社ITプロフェッショナル
P & F : 0584-77-0676
Handy : 090-9339-0676
E-mail & i-mode: ga...@it-pro.co.jp
Skype ID: dakinyj53
URL http://www.it-pro.co.jp/
Blog URLhttp://www.dakiny.com/
TinyMCE URL http://www.dakiny.com/tinymce/
----------------------------------------------
--
----------------------------------------------
蒲生トシヒロ（GAMO, Toshihiro）
〒503-0807大垣市今宿6-52-18
ソフトピアジャパン・ワークショップ24 405号室
(有)ITプロフェッショナル
P & F : 0584-77-0676
Handy : 090-9020-6417
E-mail & i-mode: ga...@it-pro.co.jp
Official http://www.it-pro.co.jp/
Private http://www.dakiny.com/
-----------------------------------------------
壱
> CustomFieldsの対案として一案。
>
> - Ruby on Railsのscaffloldのようにモデル定義からコマンドラインでのコマンド一発でモデルの新規作成・更新画面、詳細画
> 面、一覧画面、削除機能を提供する仕組みを作る
> - ↑の詳細画面、一覧画面のViewはサブのpluginを開発することで、独自Viewに切り替え可能な作りにする。
これができれば、Movable TypeがWebアプリケーションフレームワークに進化して、ポテンシャルが飛躍的にアップすると思います。
Hirotaka Ogawa
基本的に我々には我々の好きなものを作り、そしてそれを好きなライセンスで公開する自由があります。administrativeな話は後回しでいいんじゃないかと思います。
シックス・アパートに儲けていただきたいというのは私も同意見なのですが、我々がどのように「自由」を行使したにせよ(シックス・アパートに同情的に行動したにせよ)、プロフェッショナル・パッケージやテクニカル・サポートを買うに値する商品であり続けるようにするのは会社の責任においてやってもらう他ないです。
進地さんにはフロントエンド機能とバックエンド機能という説明をしましたが、私の意図をもう少し正確に述べるとこういうことです。
機能的には、
- 拡張フィールドをハンドリングするためのバックエンド機能をその他のフロントエンド部分と分離する。
- フロントエンド部分の実現によって好みのインタフェースが実現できて、みんなハッピー！
ということです。ライセンス的には、
- バックエンド機能のコードが成熟すれば、MTOSに寄贈する。MTOSの他の部分と同様にシックス・アパートが著作権を持つオープンソースとなる。
- CustomFieldsをこのバックエンドを使うように書き直す。CustomFieldsは商用ライセンスのままでOK
- その他のオープンソースプラグインもバックエンド機能を使えるので、みんなハッピー！
ということです。
つまり、一挙両得を狙おう、と。
2008/4/16 しんち <shinc...@gmail.com>:
--
Hirotaka Ogawa
http://twitter.com/ogawa
http://as-is.net/blog/
Fumiaki Yoshimatsu
>> ただ、CustomFieldsという形ではなくても、MTOSのユーザコミュニティ、SixApart、およびMTOSビジネスを考えている立場の方、みんながそれぞれに喜べる形を作っていけたらなと思っています。その点、Six
Apartの中の人のご意見聞けたらうれしいんですが＾＾<<
中の人の立場上、MTOS[でを]ホゲりたいとおっしゃっている方に、「あれをしろ、あれはするな、これは困る、これはかまわない」とかは言えないです。ご自身のお気の向くまま、自由な精神でソフトウェアを開発していただければいいと思います。MTOSがその気持ちのトリガであり、また土台になるのであれば、MTOSプロジェクトのそもそもの提供者として、うれしい限りです。シックス・アパートのビジネスどうこうはシックス・アパートがパートナー様ともども考えればいいことで、オープンソースプロジェクトの開発者が最初に考えるべきことではありません（ご自身のビジネスについては考える必要があると思います）。
ところで、Custom Fieldsの周辺は、MTOSのリポジトリを眺めていただければわかるとおり、大きく手を入れようとしています。
吉松 史彰
Movable Type 開発チーム
シックス・アパート株式会社
Hirotaka Ogawa
どのあたり？
>
> 吉松 史彰
> Movable Type 開発チーム
> シックス・アパート株式会社
>
--
野田 純生
すいません、MLの場でこういった出だしのメールをお送りするの
は気がひけるのですが、
私が以下のようなメールをしんちさんにお送りしたのは、「アルファ
サードの野田＜＜スーツの方の野田」から「アークウェブのしんち」さ
んへお送りしたということです。既にMLに流れてしまったわけで
すが、
> ただ、既に野田さん、小川さん、蒲生さん、丹羽さんには直接メール
> でお話させていただいてまして、その折に野田さんから、
>
> - MT製品版とMTOSの差が実質CustomFieldsのみである
> 状況でCustomFieldsを出してしまうのはSixApartにとって
> どうなのか？
> - SixApartがCustomFieldsをMTOSにも提供しちゃった
> ら？
> - MTOSで開発するなら、まだ存在しない機能で、かつ
> SixApartが買いとりたくなるような機能がよいのでは？
基本的にライセンスに則っていればいいわけですから、そもそも私が
(この場で)そんなことを言うのがおかしいじゃないか？という話
になっても困るので、その点は私がここでそういう発言をした、という
ことではないことにしてください(いや、本当にこんなメール送
るの気が引けるのですがすいません)。
なので、好きなものを作成すれば良いと思います。が、せっかく情報を
共有できるのであれば、既にあるものを作るよりは「まだ存在しなく
て、且つプラットフォームの魅力がアップするもの」がいいと思ってま
す。
私が個人的にあればいいと思っているのは、
(1)AdobeのFlexとかJSのライブラリを活用したアセットの
アップロードを便利にする仕組み(複数ファイル、ドラッグ＆ド
ロップ）
(2)ファイルブラウザ、画像のトリミングとか補正とかが管理画面で出
来るもの
(3)日付ベースで管理するのではなく、エクスプローラーみたいなもの
でエントリー管理できるもの
(4)管理画面の携帯対応化、携帯版ページの作成
で、4については既に簡単なものは出来ており、近いうちに何ら
かのものが公開できると思います（＜＜近いうちでなかったらごめんな
さい）。
Hirotaka Ogawa
http://code.sixapart.com/svn/movabletype/branches/feature-narrow-tables/
2008/4/16 Hirotaka Ogawa <hirotak...@gmail.com>:
Fumiaki Yoshimatsu
吉松
Hirotaka Ogawa
>
> はい、ごく近いうちにRelease-35にマージする予定です。
>
> 吉松
素晴らしい！
てことは、MTOSであらかじめバックエンド相当の機能は提供されることになるので、Six
Apartはその上でCustomFieldsを実装し直す、コミュニティはCustomFieldsもどきでも何でも実装する、ということになりますね。そして相互運用性も保証される、と。
ということで実装を開始するのはちょっと待った方がいいです。＞進地さん
> On 4/16/08, Hirotaka Ogawa <hirotak...@gmail.com> wrote:
> >
> > MT::Metaというのをどこかで見た気がしていましたが、feature-narrow-tables のことですね。
> >
> > http://code.sixapart.com/svn/movabletype/branches/feature-narrow-tables/
>
--
しんち
こんばんわ
> 僕は、昨晩入稿しましたが、MTOSでこそ、ポータルサイトを作るべきと文章を書きました。
>
> 健全なWebマーケットの育成を考えると、5万円のライセンス代を払いたくないという人の手助けにしたくないなと…。
> GPLライセンスで配布されれば使えるのなら、有償でいいと思います。
>
> CustomFieldsを凌ぐ機能にするなら、GPLライセンスで配布して商用は有償としてMTより高い値段で販売すれば、
> ＃このあたり怪しいです、商用は有償で、非商用は無償という販売方法ができたのか詳しく知りません。
> ＃ボランタリー団体からお金をとることは避けたいですね。
>
> 無償で配布するなら、複数のテンプレートを登録できて、入力サポートにつながるようなものだといいなと。
> 要はテンプレート作成モジュール。
>
> 僕はFCKeditorでやってますが、これのもっとスマートなものがあるといいなと思います。
>
>
> HTMLテンプレートを登録して、引き出すだけのものなら
> CustomFieldsの領域を侵すものではないでしょう。
なるほどです。蒲生さんにご提案いただいた方法の方が中小規模のサイト構築では直感的でわかりやすいかもですね。
しんち
こんばんわ
この機能は「A-Form」作るときに「あればいいのになー」と感じていたものでもあり、
CustomFieldsの作成の有無を問わずやってみたいなと思っています。
もう既に誰かやられるかもしれませんが＾＾；
しんち
こんばんわ
> >> ただ、CustomFieldsという形ではなくても、MTOSのユーザコミュニティ、SixApart、およびMTOSビジネスを考えている立場の方、みんながそれぞれに喜べる形を作っていけたらなと思っています。その点、Six
>
> Apartの中の人のご意見聞けたらうれしいんですが＾＾<<
>
> 中の人の立場上、MTOS[でを]ホゲりたいとおっしゃっている方に、「あれをしろ、あれはするな、これは困る、これはかまわない」とかは言えないです。ご自身のお気の向くまま、自由な精神でソフトウェアを開発していただければいいと思います。MTOSがその気持ちのトリガであり、また土台になるのであれば、MTOSプロジェクトのそもそもの提供者として、うれしい限りです。シックス・アパートのビジネスどうこうはシックス・アパートがパートナー様ともども考えればいいことで、オープンソースプロジェクトの開発者が最初に考えるべきことではありません（ご自身のビジネスについては考える必要があると思います）。
また、配慮の足りない質問をしてしまいすみません。ご意見を伺えてとてもうれしく思います。
まずは良いと自分が思うところのものを作っていこう、そう思うことができました。
ありがとうございます。
しんち
こんばんわ
> すいません、MLの場でこういった出だしのメールをお送りするの
> は気がひけるのですが、
> 私が以下のようなメールをしんちさんにお送りしたのは、「アルファ
> サードの野田＜＜スーツの方の野田」から「アークウェブのしんち」さ
> んへお送りしたということです。既にMLに流れてしまったわけで
> すが、
>
> > ただ、既に野田さん、小川さん、蒲生さん、丹羽さんには直接メール
> > でお話させていただいてまして、その折に野田さんから、
>
> > - MT製品版とMTOSの差が実質CustomFieldsのみである
> > 状況でCustomFieldsを出してしまうのはSixApartにとって
> > どうなのか？
> > - SixApartがCustomFieldsをMTOSにも提供しちゃった
> > ら？
> > - MTOSで開発するなら、まだ存在しない機能で、かつ
> > SixApartが買いとりたくなるような機能がよいのでは？
>
> 基本的にライセンスに則っていればいいわけですから、そもそも私が
> (この場で)そんなことを言うのがおかしいじゃないか？という話
> になっても困るので、その点は私がここでそういう発言をした、という
> ことではないことにしてください(いや、本当にこんなメール送
> るの気が引けるのですがすいません)。
> なので、好きなものを作成すれば良いと思います。が、せっかく情報を
> 共有できるのであれば、既にあるものを作るよりは「まだ存在しなく
> て、且つプラットフォームの魅力がアップするもの」がいいと思ってま
> す。
> 私が個人的にあればいいと思っているのは、
>
> (1)AdobeのFlexとかJSのライブラリを活用したアセットの
> アップロードを便利にする仕組み(複数ファイル、ドラッグ＆ド
> ロップ）
> (2)ファイルブラウザ、画像のトリミングとか補正とかが管理画面で出
> 来るもの
> (3)日付ベースで管理するのではなく、エクスプローラーみたいなもの
> でエントリー管理できるもの
> (4)管理画面の携帯対応化、携帯版ページの作成
> で、4については既に簡単なものは出来ており、近いうちに何ら
> かのものが公開できると思います（＜＜近いうちでなかったらごめんな
> さい）。
管理画面を携帯対応化するとなると、UIもかなり携帯用に作りこむ感じですよね。
MT4は管理画面でJavaScriptをバリバリ使っているから。
しんち
こんばんわ
> てことは、MTOSであらかじめバックエンド相当の機能は提供されることになるので、Six
> Apartはその上でCustomFieldsを実装し直す、コミュニティはCustomFieldsもどきでも何でも実装する、ということになりますね。そして相互運用性も保証される、と。
>
> ということで実装を開始するのはちょっと待った方がいいです。＞進地さん
つまりは MT Coreに小川さんが
> - 拡張フィールドをハンドリングするためのバックエンド機能をその他のフロントエンド部分と分離する。
と仰ったバックエンド相当の機能が実装されるということでしょうか。
であれば、小川さんの仰るとおり実装は待ったほうがよさげですね。
tomix
コヤマ＠キゴウラボです。
CustomFields風 OOP版の開発が始まるといううわさがを聞いていたのですが、
ここで話題があがっていたのですね。MLをまとめて受信にしていたのでいままで
気がつきませんでした。今スレッドを読みおわりました。
技術者でなく、デザイン上がりのディレクター・プロデューサーとしては
ビジネスにおいてMTOSとMTの提案をどうわけて行くかという点が気になって
いましたので、6Aさんのスタンスがわかってちょっと安心しました。
ただ、私もMTOSを、プワマンズMTにはしたくないと思っていましたので、
そのために参加する方向（≒技術者でない自分が協力すべき領域や方法）を考えていました。
小川さんや、しんちさんの考えているような、フロントとバックの分離やフレームワーク化が
高速化などと並んで、最終的な目的地となるなと思っていました。その結果、フロント部分
のアイデアの実現が容易となって、MTOSの活用範囲が広がるようなものが技術力のない
人でも作れるようになってくると思います。
ただ、今回の話題に出た内容に、デザイナーとしての希望を具体的にいうと
> - Ruby on Railsのscaffloldのようにモデル定義からコマンドラインでのコマンド一発でモデルの新規作成・更新画面、詳細画
> 面、一覧画面、削除機能を提供する仕組みを作る
> - ↑の詳細画面、一覧画面のViewはサブのpluginを開発することで、独自Viewに切り替え可能な作りにする。
極力 PuerMTMLで記述できるような方法が理想だな（それが可能なコントロールを生成する）と思います。
HTMLタグライクにVIEWが作れるというところに、MTがここまでひろがったアドバンテージがあると思うから
です。その上にいろんなアイデアが花開いてほしいです。(coldfusionもタグベースですが、それが動作する
安い共用サーバーが国内に皆無だったという点で広がってないのではないかと）
ニュアンスとしては、ウェブアプリケーションフレームワークというより、ウエブパブリッシングフレームワークとか
ウエブコミュニケーションフレームワークとか、要するに、オリジナルCMS/コミュニティをつくるためのフレーム
ワークといった感じになっていくといいなぁと。
CustomFieldsは、まだあまり使ってないのでありがたさがわかっていないので、ちょっといい加減な意見かもしれませんが、XML的にメタにど
んどん、要素を区切って行きたい場合は、野田さんとこの製品のほうがいいのかなとか思っています。
もっと行くと、CustomFieldsではなく、本文部分にメタ的なタグをつけて要素を区切っていくことでミニマルなCustomFields風拡張
を可能とするものもあってもよいのではないかと、デザイン的にはCSSとの要素の紐付けですので、タグに接頭辞をつけるか、親子関係にすれば、接頭辞か
親で共通classにひもづけてあげるような、条件分岐をCSSテンプレートにすればOKとか（これなら現状でもすでに可能？） もしかしたらFCKの
カスタマイズで実現できる
のではないかと、まだコードをみてないまま妄想中です。
様は、CustomFieldsってあるコンテンツでは、制限がつけることでコンテンツの統一感を出せると同時に
あるコンテンツでは、やっぱり制限がつけられない、または要素が多すぎる、例外が多すぎるってことにも
なるとおもうので、そういった違う切り口が必要なときに対応できる、CustomFields風何かを考えるという
なら多いに意味があるとおもうのです。
その他でいうと、1～4はまさに自分も今すぐ欲しいって感じで
> (1)AdobeのFlexとかJSのライブラリを活用したアセットの
> アップロードを便利にする仕組み(複数ファイル、ドラッグ＆ド
> ロップ）
> (2)ファイルブラウザ、画像のトリミングとか補正とかが管理画面で出
> 来るもの
> (3)日付ベースで管理するのではなく、エクスプローラーみたいなもの
> でエントリー管理できるもの
> (4)管理画面の携帯対応化、携帯版ページの作成
FTP対象ディレクトリーは、管理者側から権限とひもづけて制限できる、ファイル名の競合管理も
やってくれるみたいなものでしょうか？ 結構重い物になると思うので、すでにあるOOPをフォーク
して組み込むとか、マッシュアップしてPhotoshop ExpressやFicker的なサービスとの連携手段
を作るとかありそうです。
CMS時代は、コンテンツ制作能力を広げていかないといけないですよね。
文章は、勉強だけでなんとかなるけど、画像はソフト買ってくれというのがありますのでひとつになっていると
確かにワークフローがシンプルになりますね。
> (3)日付ベースで管理するのではなく、エクスプローラーみたいなもの
> でエントリー管理できるもの
これまさにLP5で僕が質問したもので、その時鷹野さんに、それではあなたが作ってください
という突っ込みで終わってしまったのですが、最初につくるプラグインとしては超重そうです。
まずは、yahooUIの、datatableを、管理画面の記事一覧に組み込むことができないかな的
なところから時間をみつけて挑戦してみようかと思っていたりします。（これだけでソート順が
変えられるから） これでエクスプローラーの右側詳細表示風はできるかなと
エクスプローラーの肝心な左側は、その並びが重要なので、藤本さんのカテゴリーソート
プラグインの延長にあるんじゃないかなとか思っています。カテゴリーのドラッグドロップ
での並び順、階層変更や、逆にタグ別、月別みたいな切り替えもほしいところ。紙Copi
の左側風とか、Macのフォルダー表示（エクスプローラーよりこっちが個人的には好き）
と、OSX10.5のFinder左側のような、ショットカット機能の組み合わせとか....UIの切り口
はエクスプローラー以外にいっぱいあります（わかりやすく質問ではエクスプローラーと
言ったのですが...)
＊データグリッドの例
http://developer.yahoo.com/yui/datatable/
http://extjs.com/deploy/dev/examples/grid/array-grid.html
http://extjs.com/deploy/dev/examples/grid/grouping.html
http://extjs.com/deploy/dev/examples/tree/column-tree.html
http://www.smashingmagazine.com/2007/05/30/tables-and-data-grids-with-ajax-dhtml-javascript/
＃extjs.comにはもっといっぱい事例があります。LGPL3.0とOEM / Reseller Licenseのデュアルライセンス
＃なんですが、これってMTOSにいれてもライセンス的に問題なし？ MTにフィードバックすると有償？
> (4)管理画面の携帯対応化、携帯版ページの作成
これは、私自身がまさに、貧乏NPOのスタッフでもあり、そのNPOが視覚障害者と高齢者の情報バリアフリー
支援がテーマなので、切実に希望しているところですが、上記のような手段がふえればふえるほど、現状、
DOMを解釈できる音声ブラウザーはないので、代替手段としての、アクセシブルな管理画面がほしいです。
ただし、障害者は特別扱いをすると嫌がります。なのでテキスト版とかは、情報もすくないのではないかとまず
使いません。音声読み上げシステムも自分仕様にカスタマイズした音声ブラウザーとぶつかるのでまず使い
ません。ゆえに、高齢者や携帯や、モバイル中といったときにさくっと作業ができる一般の人も対象にした、
オルタナティブな管理画面というものを構想できないかなと思っています。
> ＃ボランタリー団体からお金をとることは避けたいですね。
うれしいお話なんですが、スタッフはボランティアだけど、組織は億を肥える助成金や、税金対策でぼろもうけ
している、NPO、NGOも多い（というか、そのほうが多い？）というのも、実態だったりします。NPOも非営利
ではあるけど、あくまでもその営利は、株主営利を目的にしないということで、目的達成ためのリソースは
稼がないとサスナブルにサービスを提供していけません。その辺の方法のヒントを、まさにオープンソース
コミュニティと事業活動のWin-Winな関係というところに求めて行きたいと思っています。
別のオープンソースコミュニティに参加したとき、やっぱりコードで貢献できないと辛い感じをもったことがあります
コードで貢献できるよう、Perlの再勉強中です。（いまとっても悔しいので）また、デザインやドキュメント、アイデア
作りや戦略作りといった部分でも積極的に貢献していきたい（またそういう人も巻き込みたい）とおもっています。
いずれ、日本語むけ広報とか、コミュニティ側でも分担することになるのかな（英語も弱かったり....）
各自のモチベーションだけが命なので、やりたいことをやるが基本だとおもいますが、
分散しても充実するだけのコミュニティの成熟はこれからだと思うので、とりあえずやっていることは
声をだして、興味のある人を巻き込むなり、車輪の再発明にならないようにしたりといったことから
はじめるってことですね（今回のCustomFields代替というテーマの呼びかけがまさにそれだったと
いうことですね）
まとめてコメントで長文かつちょっとスレはずれで恐縮でした
僕の考えは以上です。
-
小山 智久
コヤマ トモヒサ
Koyama Tomohisa
to...@kigoulab.co.jp
----------------------------------
情報伝達の設計と意匠
有限会社キゴウラボ
-
150-0031
東京都渋谷区桜丘町４－１７
チェリーガーデン６０２
T 03 5784 6797
F 03 5784 6787
-
らしさのデザイン/問題解決デザイン
http://www.kigoulab.jp/
-
ホームページラボ
http://www.homepagelab.jp/
小規模ホームページ相談サービス
-
広報部長犬『トォイ』のブログ
http://kigoulab.typepad.jp/towy/
--------------------------------
koy...@harmony-web.org
----------------------------------
ＮＰＯ法人ハーモニー・アイ CSR推進事業部
150-0031
東京都渋谷区桜丘町４－１７
チェリーガーデン６０２
キゴウラボ内
T 03 5784 6797
F 03 5784 6787
http://www.harmony-web.org
--------------------------------
tomix
コヤマ＠キゴウラボです。
CustomFields風 OOP版の開発が始まるといううわさがを聞いていたのですが、
ここで話題があがっていたのですね。MLをまとめて受信にしていたのでいままで
気がつきませんでした。今スレッドを読みおわりました。
ビジネスにおいてMTOSとMTの提案をどうわけて行くかという点が気になって
いましたので、6Aさんのスタンスがわかってちょっと安心しました。
ただ、私もMTOSを、プワマンズMTにはしたくないと思っていましたので、どういった切り口
でわけていくのかを考えていましたが、理想としてはMTOSがあることで、新しい切り口や、
ユーザー毎にあったウェブ発信手段が増えていくこと、またそのソリューションや設計といった
ビジネスが考えられるかなと思っていました。
そのためにも、自分が貢献できること（≒技術者でない自分が協力すべき領域や方法）を
いろいろと考えていました。
小川さんや、しんちさんの考えているような、フロントとバックの分離やフレームワーク化が
高速化などと並んで、最終的な目的地となるなと思っていました。その結果、ユーザーサイド
の目的、アイデアや実現化が極力フロント部分だけで出来る様になって、MTOSの活用範囲
ただ、今回の話題に出た内容に、デザイナーとしての希望を具体的にいうと
> - Ruby on Railsのscaffloldのようにモデル定義からコマンドラインでのコマンド一発でモデルの新規作成・更新画面、詳細画
> 面、一覧画面、削除機能を提供する仕組みを作る
> - ↑の詳細画面、一覧画面のViewはサブのpluginを開発することで、独自Viewに切り替え可能な作りにする。
といった、RORのような方式でMVCを自動生成する場合であっても、VIEWはエントリーでも管理画面でも、
ってある意味コントロールですよね？）が理想だなと思います。
HTMLタグライクにVIEWが作れるというところに、MTがここまでひろがったアドバンテージがあると思うから
です。その上にいろんなアイデアが花開いてほしいです。(coldfusionもタグベースですが、それが動作する
安い共用サーバーが国内に皆無だったという点で広がってないのではないかと）
ウエブコミュニケーションフレームワークとか、要するにオリジナルな情報発信やコミュニケーション手段を
つくるためのコアフレームワークといった感じになっていくといいなぁと。
--------------------------------
Hirotaka Ogawa
2008/4/16 しんち <shinc...@gmail.com>:
えーっと、それくらいの機能が実装されているのかと思いましたが、違いました。
もともとCustomFieldsなどはmt_entryテーブルのentry_metaカラムにシリアライズしたデータを格納するようになっていました。この方法にはいくつか問題があって、代表的なものを挙げると、
(1) entry_metaは各mt_entryに一個しかないため、複数のプラグインが別の目的でentry_metaをハンドルする場合、各々他のプラグインが操作する領域を壊さないように留意する必要があった。
(2) MT::Entryをロードするたびに不必要なblobを一緒に読み込むことになって非効率だった。
などなどです。
feature-narrow-tablesはこの問題を解決するための臨時branchで、その内容はすでに最新の開発branch
(release-35)に反映されています。
この変更では、mt_entryテーブルからentry_metaカラムがなくなり、mt_entry_metaという別テーブルに格納されることになります。これによりメリットは、
(1) プラグイン(アプリケーション)ごとに別のmt_entry_metaにデータを格納すればいいので、安全、簡単。
(2) MT::Entryをロードするたびに不必要なblobを一緒に読み込む必要がなく、メモリー利用効率がよい。
(3) 任意のMT::Objectにmetaデータを付与できる。
あたりでしょうか。
他にも実装上の工夫として、mt_XXX_metaテーブルは型ポリモルフィズムみたいなものを支援する機構があります。
メタデータとして構造のないデータ(例えば、テキストや数値、日付など)を格納する場合、いちいちblobに変換して入出力するとシリアライズ・デシリアライズのオーバーヘッドがかかるだけなのでできればやりたくないわけです。feature-narrow-tablesの実装ではデータ型ごとにmt_XXX_metaテーブルの適切なカラムに格納するようになっていて、構造のあるデータを格納するときだけblobにシリアライズして格納するようにできるようです。
> であれば、小川さんの仰るとおり実装は待ったほうがよさげですね。
しんち
こんばんわ
(...)
> > つまりは MT Coreに小川さんが
>
> > > - 拡張フィールドをハンドリングするためのバックエンド機能をその他のフロントエンド部分と分離する。
>
> > と仰ったバックエンド相当の機能が実装されるということでしょうか。
>
> えーっと、それくらいの機能が実装されているのかと思いましたが、違いました。
>
> もともとCustomFieldsなどはmt_entryテーブルのentry_metaカラムにシリアライズしたデータを格納するようになっていました。この方法にはいくつか問題があって、代表的なものを挙げると、
>
> (1) entry_metaは各mt_entryに一個しかないため、複数のプラグインが別の目的でentry_metaをハンドルする場合、各々他のプラグインが操作する領域を壊さないように留意する必要があった。
> (2) MT::Entryをロードするたびに不必要なblobを一緒に読み込むことになって非効率だった。
>
> などなどです。
>
> feature-narrow-tablesはこの問題を解決するための臨時branchで、その内容はすでに最新の開発branch
> (release-35)に反映されています。
>
> この変更では、mt_entryテーブルからentry_metaカラムがなくなり、mt_entry_metaという別テーブルに格納されることになります。これによりメリットは、
>
> (1) プラグイン(アプリケーション)ごとに別のmt_entry_metaにデータを格納すればいいので、安全、簡単。
> (2) MT::Entryをロードするたびに不必要なblobを一緒に読み込む必要がなく、メモリー利用効率がよい。
> (3) 任意のMT::Objectにmetaデータを付与できる。
>
> あたりでしょうか。
>
> 他にも実装上の工夫として、mt_XXX_metaテーブルは型ポリモルフィズムみたいなものを支援する機構があります。
>
> メタデータとして構造のないデータ(例えば、テキストや数値、日付など)を格納する場合、いちいちblobに変換して入出力するとシリアライズ・デシリアライズのオーバーヘッドがかかるだけなのでできればやりたくないわけです。feature-narrow-tablesの実装ではデータ型ごとにmt_XXX_metaテーブルの適切なカラムに格納するようになっていて、構造のあるデータを格納するときだけblobにシリアライズして格納するようにできるようです。
バックエンドの構築を考えるときは、(3)が特にうれしいところですね。
MT::Entryに縛られることなく、MT::Objectのサブクラスとして定義して使っていけると。
壱
MT4.15β4を使って、プラグインからメタフィールドにアクセスする方法を調べてみました。
記事としてブログにアップしました。
http://www.h-fj.com/blog/archives/2008/04/24-152059.php
しんち
こんにちは
> MT4.15β4を使って、プラグインからメタフィールドにアクセスする方法を調べてみました。
> 記事としてブログにアップしました。
>
> http://www.h-fj.com/blog/archives/2008/04/24-152059.php
> loadメソッドでオブジェクトを読み込むと、メタデータも同時に読み込まれ、オブジェクトのプロパティに自動的にマッピングされます。
これによって、メタデータのフィールドは、既存のフィールドと同じように、「オブジェクト->プロパティ」の形でアクセスすることができます。
↑凄い便利ですねー。
「データ型 meta」に指定できるデータ型はCustomFieldsが提供するデータ型と同じなんですかね。
Hirotaka Ogawa
もう少しgeneralな型になります。
この仕組みを使ったCustomFieldsの実装としては大まかに2種類あり得ます。
一つは、CustomFieldsデータの連想配列をシリアライズしてblobデータとして一つのメタデータに格納する方法。CustomFieldsのもともとの実装をなるべく変更しないようにするとこの方法を選択することになります。
もう一つは、CustomFieldsのフィールドごとにメタデータに格納する方法。CustomFieldsの実装をかなり変更する必要がありますが、テキストデータがそのままDBに格納されるので管理しやすくなります。
性能の面では、前者はシリアライズ・デシリアライズするのにオーバーヘッドがかかるのに対して、メタデータを取り出すのに複数のローにアクセスする必要があるため(実装によっては複数回のSELECTが必要になるため)オーバーヘッドがかかります。一つのオブジェクトに関連付けられるフィールドが多数あることを仮定すると、そのうち一つだけにアクセスする場合には前者のオーバーヘッドが後者を上回るでしょうし、全部にアクセスする場合には後者のオーバーヘッドが前者を上回ることになるでしょう。つまり、トレードオフの関係です。
Hirotaka Ogawa
荒木さんの記事 http://www.koikikukan.com/archives/2008/04/26-003333.php
によると、後者の方法で実装されたようですね。
これならオープンソース版のXXFieldsを実装して、CustomFieldsとの互換性を実現するのは簡単そうですね。
＃MT::Fieldの定義部分もMTOSに入れてくれないものかなあ、と思わないでもないですけど。
しんち
おはようございます
On 4月25日, 午前12:15, "Hirotaka Ogawa" <hirotaka.og...@gmail.com> wrote:
> 2008/4/24 しんち <shinchi...@gmail.com>:
理の時が多いイメージです。ほとんどのケースでは後者がパフォーマンスの観点からも優位かなと。あと、TEXTでDBに入っていれば、保守が断然やりや
すいですよね。