ブログ型コンテンツへの対応

プログラム(機能)関連の開発の話題
返信する
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

ブログ型コンテンツへの対応

投稿記事 by yama »

6月の予定ですが、早いうちにネタを振っておきます。

http://dev.modx.ayd.jp/i002/manager/
user : modx
pass : modxmodx

とりあえず去年の11月末の時点で、こんな感じのサンプルを作ってます。おおまかなイメージはこれでよいと思うのですが、細かい問題がいろいろあります。この仕組みはMODxがもともと備えているメソッドを利用しているのですが、これが使いづらいのが原因。で、そのレベルからちゃんと作り込んでいこうという腹づもりです。

他に考えているのは、そもそもツリーにモジュールをぶら下げることができると面白いのでは?ということ。URLクエリで渡すデータは、MODxの場合はシステムとしては「id」だけなので、わりと自由に使えるはずなんですね。実際、Jotなんかがそうですが。そのへんがヒントになるのではと考えてます。もしかするとWordPressやSMFをモジュールとしてぶら下げることも可能ではと。管理画面まで統合するのは無理ですが。

Windowsのエクスプローラだと、フォルダ右クリックのプロパティでサブフォルダの設定を一括変更できたりしますね。そういうインターフェイスも面白いかなと思ってます。たとえばテンプレートを全部揃えたりとか。スタック型という話とは少しズレますが、コード的には同じ部分をさわります。

以上、何かアイデアあればよろしくお願いします。
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: ブログ型コンテンツへの対応

投稿記事 by sama55 »

触ってみました。
yama さんが書きました:6月の予定ですが、早いうちにネタを振っておきます。
http://dev.modx.ayd.jp/i002/manager/
user : modx
pass : modxmodx

とりあえず去年の11月末の時点で、こんな感じのサンプルを作ってます。おおまかなイメージはこれでよいと思うのですが、細かい問題がいろいろあります。この仕組みはMODxがもともと備えているメソッドを利用しているのですが、これが使いづらいのが原因。で、そのレベルからちゃんと作り込んでいこうという腹づもりです。
操作に迷ったので少しだけ補完しますね。
  • サイトを表示後、基本認証画面で上記IDとPWを入力して認証をパスします
  • ログイン画面で上記IDとPWを入力して管理画面に入ります
  • 左側ツリーの「Weblog」をクリック >>> スタック型(ブログ)リソースリストが表示されます
  • 右上のEdit・Move・Duplicate・Delete・Previewの各メニューボタンは、Weblogリソースに対する操作
WordPressと対比して思ったことを列挙してみます。
  • リソースリストにカテゴリは表示しない  ※属性の違うリソースが混在すると画面(機能)操作が難しくなるから
  • ツリーにカテゴリを表示(リソースの移動で必要) ※カテゴリ(親)リソースは"Show branches on a tree"属性に関わらずツリーに強制表示
  • リソースリストに「カテゴリID欄」を追加してリソースが属するカテゴリを明示
  • 未分類(デフォルト)カテゴリが恐らく必要(未分類は削除できない)
  • 一括操作機能(リソース行ごとにチェックボックスを付与)が必要  ※恐らく付けるつもりですよね。^^
  • フィルタ(カテゴリによる絞込み表示)機能が必要
  • カテゴリの並び替え機能が必要  ※WordPressの http://geekyweekly.com/mycategoryorder 的なもの
とりあえずこんな感じ。  :mrgreen:
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: ブログ型コンテンツへの対応

投稿記事 by yama »

インラインコメントで失礼します
sama55 さんが書きました:リソースリストにカテゴリは表示しない  ※属性の違うリソースが混在すると画面(機能)操作が難しくなるから
Windowsのエクスプローラでディレクトリが最初に表示されるイメージに近くて分かりやすいかな?という気はするのですが・・検討してみます。
sama55 さんが書きました:ツリーにカテゴリを表示(リソースの移動で必要) ※カテゴリ(親)リソースは"Show branches on a tree"属性に関わらずツリーに強制表示
これは必須ですね
sama55 さんが書きました:リソースリストに「カテゴリID欄」を追加してリソースが属するカテゴリを明示
一般的なブログ型CMSに近いイメージですね。そのような見せ方のほうが分かりやすい人も多いと思うので工夫してみます。
sama55 さんが書きました:未分類(デフォルト)カテゴリが恐らく必要(未分類は削除できない)
現状、カテゴリーは「親フォルダ」で表現しています。ブログコンテナ以下のどの親フォルダにも属していないリソースをそのように見立てるイメージで考え中。
sama55 さんが書きました:一括操作機能(リソース行ごとにチェックボックスを付与)が必要  ※恐らく付けるつもりですよね。^^
できればそのようにしたいです。
sama55 さんが書きました:フィルタ(カテゴリによる絞込み表示)機能が必要
ブログ型CMS風の見せ方にする場合は必要ですね。
sama55 さんが書きました:カテゴリの並び替え機能が必要  ※WordPressの http://geekyweekly.com/mycategoryorder 的なもの
DocManagerでもできると思いますが、できれば実装してみます。

ちょっと悩ましいのが「Show branches on a tree」属性で本当にいいのかなあ。というところです。MODxが今後どういうふうに進化していくのかを見据えたうえで、適切なフラグを立てるべきだと思います。なんとなく、ツリーに表示する・しないだけの問題ではないだろうという気はしています。たとえば、ウェブリンクと別の次元で実装するとあとでややこしいことにならない?とか。通常リソース・ウェブリンク・スタック型リソースの3種類を実装したら完成ってことでもないよね?ということも気になります。
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: ブログ型コンテンツへの対応

投稿記事 by sama55 »

yama さんが書きました:ちょっと悩ましいのが「Show branches on a tree」属性で本当にいいのかなあ。というところです。MODxが今後どういうふうに進化していくのかを見据えたうえで、適切なフラグを立てるべきだと思います。なんとなく、ツリーに表示する・しないだけの問題ではないだろうという気はしています。たとえば、ウェブリンクと別の次元で実装するとあとでややこしいことにならない?とか。通常リソース・ウェブリンク・スタック型リソースの3種類を実装したら完成ってことでもないよね?ということも気になります。
確かに悩みどころですね。。。
MODxの代名詞ともいうべきリソースツリーでのスタック型コンテンツの扱いに無理があることがそもそもの発端ですし、、、かと言ってMODxユーザーが慣れ親しんでいるエクスプローラライクなリソースの操作性も捨てがたい。。。自分はブログは制作経験は結構ありますが運用は初心者も同然です。実際運用してみて思ったのは、最初はかなりアバウトな括りで記事を書いていましたが、閲覧者のことを考えて、徐々にカテゴリを細分化していくようになりました。元々日記にはカテゴリなんてものはなく、日々ズルズルと書いていくのが日記本来の姿かもしれません。でも、実情を踏まて考えると、1つのカテゴリに数千・数万といったリソースがぶらさがることはそれほど多くないのではないかと。前置きが長くなってしまいましたが、要はShow branches on a treeは今のままでいいのではないかと(この件とは切り離してMODxのネイティブ機能として提案してもイイような・・・)。また、別な名前を付けるとしたら・・・”Show children on a tree” とか?(同じかな ^^;)
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: ブログ型コンテンツへの対応

投稿記事 by yama »

イメージ的にはSilverStripeのツリーのような感じがよいなと考えてます。この場合、ブログ以外にもフォーラムやギャラリー、通販カートなどをぶら下げることができます。MODxには現在でもインテグレーションという形の拡張が存在するわけだし、このへんの考え方を突き詰めたうえで先に進むのがよいかなと思ってます。

MODxの場合、リソースとコンテナという違いもあれば、リソースとウェブリンクという違いもあるという見方もあって、このへんがすっきりしないため迷ってます。前者の場合は単純にリソース変数の違いですが、後者だとリソースタイプの違いで、投稿画面の構成も変わってくる。

そもそもリソースって何?というレベルから、よく考える必要があるのではと思ってます。MODxである以上、Revoと異なるモデルを組むわけにはいかないので、Revoの柔軟な拡張性の延長線上で考える必要もありますね。とかとか、考えてます。
アバター
kurosquare
メンバー
メンバー
記事: 6
登録日時: 2009年8月15日(土) 23:03

Re: ブログ型コンテンツへの対応

投稿記事 by kurosquare »

横からコメント失礼します。
ブログ以外にもフォーラムやギャラリー、通販カートなどをぶら下げることができます。
MODxをフレームワークというか、プラットフォームとして活用したいというニーズは、意外と多い気がします。(単に設計思想が私の好みというのはさておいて・・・)
もしかするとWordPressやSMFをモジュールとしてぶら下げることも可能ではと。管理画面まで統合するのは無理ですが。
今までの経験からしますと、専用モジュールとして提供されながらも、やはりどうしても人手不足でバージョンアップされないまま、開発が停滞してしまうケースをいくつか目にしてきましたので、そうならないように柔軟に対応できるとナイスですね!
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: ブログ型コンテンツへの対応

投稿記事 by sama55 »

kurosquare さんが書きました:
もしかするとWordPressやSMFをモジュールとしてぶら下げることも可能ではと。管理画面まで統合するのは無理ですが。
今までの経験からしますと、専用モジュールとして提供されながらも、やはりどうしても人手不足でバージョンアップされないまま、開発が停滞してしまうケースをいくつか目にしてきましたので、そうならないように柔軟に対応できるとナイスですね!
仰るとおりで、自分もそれが気がかりなんです。他の慎重なプロダクトと比べるとMODxの改版サイクルは短く、マイナーバージョンアップでも根っこの仕様が変わることもあります。特にインテグレータ系部品はその影響を受けやすく、アドオン開発者がコアの変動に付いていくのは相当な覚悟と苦労があると思います。MODxの内部的な変更をなるべく外に見せないことを目的としたWordPressやSMFなどの他システム連携を専門とするミドルウェア的な仕組みがコア内にあると、部品開発者も安心して物づくりができるのかもしれません。

というわけで、やまさんのブログコンテンツを扱う仕組みをコア内に実装する試みに大きな期待を寄せています。
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: ブログ型コンテンツへの対応

投稿記事 by yama »

書いてるうちに少し整理がついてきたのですが、今回の件はブログにも使えるしフォーラムにも使える。ギャラリーなどにも使える。するとコンテンツの扱い方もそれぞれ多少は違うわけで、単に「ツリーにサブリソースを表示する・しない」だけの違いにとどめず、これ専用の第3のリソース形態を考案する必要があると思います。Revoへの移行が可能な形であるべきなので、そのへんが難しいかもしれませんが。documentObjectの種類を増やすのはアリなのかな。「ツリーに表示する・しない」でも1つは増えるわけですが・・Revoの正式版が出る前にしっかり考えたほうがよいかもしれませんね。

今回の件の延長線上にインテグレータとの連携があるとしたら(あるべきだと思います)、そのへんの仕掛けを柔軟かつシンプルに考える必要がありますね。見せ方が違うだけで中身は今までのMODxの仕組みそのまま、という感じにできればベストだと思います。通常リソース・ウェブリンク・コンテナ・ブログ型コンテンツ・インテグレータ、いろいろあるけど基本は同じ。みたいな。WordPressインテグレータで言うと[*content*]と[!WordPressIntegrator!]を差し替えてるようですが、このへんの差し替えの仕組みが何か分かりやすいものがあるとよいのかも。(見当違いなこと考えてるかも)

SMFインテグレータはたしか出力は連携してないですね。パーツ的に新着を取得したりとかはできるけど、フォーラムそれ自体の出力はMODx側では面倒を見てないと思います(記憶違いだったらすみません)。URLはMODxの管理下ですね。こういう連携も考えると、つまりどういうことだろう。また考えてみます・・
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: ブログ型コンテンツへの対応

投稿記事 by sama55 »

yama さんが書きました:書いてるうちに少し整理がついてきたのですが、今回の件はブログにも使えるしフォーラムにも使える。ギャラリーなどにも使える。するとコンテンツの扱い方もそれぞれ多少は違うわけで、単に「ツリーにサブリソースを表示する・しない」だけの違いにとどめず、これ専用の第3のリソース形態を考案する必要があると思います。Revoへの移行が可能な形であるべきなので、そのへんが難しいかもしれませんが。documentObjectの種類を増やすのはアリなのかな。「ツリーに表示する・しない」でも1つは増えるわけですが・・Revoの正式版が出る前にしっかり考えたほうがよいかもしれませんね。
ですね。技量は問われるものの拡張のし易さは圧倒的にRevoですが、”ドキュメント”から”リソース”という表現に変えたEvoも折角定義を変えたんですから、リソースの解釈や幅を広げていくのは当然アリかと。
yama さんが書きました:今回の件の延長線上にインテグレータとの連携があるとしたら(あるべきだと思います)、そのへんの仕掛けを柔軟かつシンプルに考える必要がありますね。見せ方が違うだけで中身は今までのMODxの仕組みそのまま、という感じにできればベストだと思います。通常リソース・ウェブリンク・コンテナ・ブログ型コンテンツ・インテグレータ、いろいろあるけど基本は同じ。みたいな。WordPressインテグレータで言うと[*content*]と[!WordPressIntegrator!]を差し替えてるようですが、このへんの差し替えの仕組みが何か分かりやすいものがあるとよいのかも。(見当違いなこと考えてるかも)
yamaさんに言われてSilverStripeを久しぶりに見ましたが、丁度MODxと特化システムの中間ぐらいの位置づけで設計されてて、いやはや良く出来てますね。 ^^
yama さんが書きました:SMFインテグレータはたしか出力は連携してないですね。パーツ的に新着を取得したりとかはできるけど、フォーラムそれ自体の出力はMODx側では面倒を見てないと思います(記憶違いだったらすみません)。URLはMODxの管理下ですね。こういう連携も考えると、つまりどういうことだろう。また考えてみます・・
これこれ > SMF Forum Integration (MODxとSMFの連携)
SMFのデータはSSIで柔軟に引っこ抜けます。SimplePortalなどもSSIに依存してて、SMFのコアと「付かず離れず」的な位置づけで組まれてます。Revoはともかく熟成期に入ったEvoは、この辺のしつらえに力を入れても良いかと・・・CMS界の帝王の血筋を引くMODxとしては、SSIと逆(データを出すのではなく受け入れる)柔軟な仕組みが是非欲しいところ。
アバター
yama
管理人
記事: 3236
登録日時: 2009年7月29日(水) 02:50

Re: ブログ型コンテンツへの対応

投稿記事 by yama »

なるほど、SMFインテグレータはそんな感じで。シームレスな感じで組み込むのは面倒ですが、それは納得せざるを得ないですね。他のCMSでも事情は同じでしょうし。それでも、全く個別に独立して運用するよりは大幅に便利。

@bindingsのような、データソースの考え方を煮詰めると面白い連携ができそうな気がします。MODx側のリソースIDとSMF側のエントリーIDの同期をどう考えるかとか、細かい課題はいろいろありそうですが。[*pagetitle*]や[*content*]に相当するものはSMF側にもあるわけなので、そのへんのイメージから外れずに考えるとヒントが見つかりそうです。
返信する