開発中の1.0について

ふだん@eval使わないのでピンとこなかったのですが、少し考えてみました。

@ EVAL if ($modx->getLoginUserID()) return ’Logout’; else return ’Login’;
サンプルコンテンツには上記のような記述がありますが、これだったらテンプレート変数じゃなくてスニペットにしちゃったほうがいいような気がします。@EVALの使いどころとしては、sama55さんが考えるように、evalした結果を編集画面にひな型として出力するのがフレームワーク的にはスマートですね。

あるいは、@EVALは現在の仕様のまま残しておいて、phpに慣れている投稿者にとって便利なものという位置づけにしておいて、テンプレート変数作成画面の「入力タイプ」で、php記述・展開ができるタイプのパーツを増やすなどの方法もよいのでは？と思いました。他にもいろいろ考えられますが、今の仕様はなんとなくしっくりこない感じはします。

Quote from: yama at May 21, 2009, 03:56 AM

テンプレート変数作成画面の「入力タイプ」で、php記述・展開ができるタイプのパーツを増やす方法

なるほど・・・テンプレート変数のパーツ追加はやったことがあるのですが意外に簡単に追加できました。
でも結局コアを改造することになるんですよね。。。eZのようにソース（クラス）のオーバーライドができれば、本体ソースは触らずにいけるんですが無理な相談。やっぱりRevo待ちってことに。　＾＾；

Quote from: yama at May 21, 2009, 03:56 AM

今の仕様はなんとなくしっくりこない感じはします。

そうなんですよね。。。使用者（ノンプログラマ）不在な実装が目立ちますよね。
つい先日SkinGraftを少しだけ触ってみたのですが、テーマ機能をmodxに追加するものと思ったら、その実体はテーマ作成用ツールなんですよね。最初からその機能範囲に収めるつもりで設計したのならそういうものと割り切ればいいわけですが、作れたって使えなかったら意味ないのに・・・みたいな。modxの自由度が気に入って使ってるわけですが、作る楽しみは味わえるものの、なぜか使う楽しみが味わえない。。。（フレームワーク志向のシステムだから？）

Quote from: sama55 at May 21, 2009, 06:09 AM

でも結局コアを改造することになるんですよね。。。eZのようにソース（クラス）のオーバーライドができれば、本体ソースは触らずにいけるんですが無理な相談。やっぱりRevo待ちってことに。　＾＾；

Evo構築中の今だったら改造じゃなくてコアの改良ということで提案できるいいタイミングのように思います。
これなら仕様を変えるわけじゃなくて便利なパーツの追加なので混乱なさそうですし、いいのでは。

0.9.6.3 から evolution1.0J-b1-r146 へのアップグレードでの不具合です。
0.9.6.3 から evolution1.0J-b1 へのアップグレードでは未確認です。

アップグレード後プラグインの QuickEdit を「編集/保存」したあとのプレビューで下記のエラーを確認できます（QuickEditにはなにも変更は加えていません、0.9.6.3以前のバージョンからアップグレードを繰り返してきた場合にカテゴリーが外れてしまうためにカテゴリーを設定するための保存で、この現象を確認しました）

エラーメッセージ下線部分が肝です。

« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: Output::include_once() [function.Output-include-once]: Unable to access /virtual/xxx/public_html/modx//virtual/xxx/public_html/modx/assets/modules/quick_edit/lang/english.inc.php
Error type/ Nr.: Warning - 2
File: /virtual/xxx/public_html/modx/assets/modules/quick_edit/output.class.inc.php
Line: 55
Line 55 source: include_once ($qe_eng_path);

Parser timing
MySQL: 0.0005 s (3 Requests)
PHP: 0.0162 s
Total: 0.0167 s

了解です、チケット上げときますー

samaさん

にっくです。ご無沙汰しています。
ちょっと本文と関係のないところで反応しますが･･･。

Quote from: sama55 at May 21, 2009, 06:09 AM

つい先日SkinGraftを少しだけ触ってみたのですが、テーマ機能をmodxに追加するものと思ったら、その実体はテーマ作成用ツールなんですよね。最初からその機能範囲に収めるつもりで設計したのならそういうものと割り切ればいいわけですが、作れたって使えなかったら意味ないのに・・・みたいな。modxの自由度が気に入って使ってるわけですが、作る楽しみは味わえるものの、なぜか使う楽しみが味わえない。。。（フレームワーク志向のシステムだから？）

SkinGraftですが、動作はするようです。
開発中の日本語版Evo1.0.0jと0.9.6.3で動きました。
（僕は恥ずかしながら、このモジュールの存在を完全に見落としていました）

SkinGraftは「テンプレートインストーラー」兼「対応テンプレート生成用定義ファイル作成モジュール」だそうです。

SkinGraftレディなテンプレートは、ほぼWordPress感覚で一発インストールが可能。
モジュールの管理画面からテンプレート設定も可能でした。
オリジナルテンプレートセットを作成していますが、いまいちうまくいかず。
ここを確認したら、リソースとして配布できそうです。

日本語化ファイルと日本語マニュアルを作成したので、もしご入用があればお送りいたしますー。

にっくさんお久しぶりです。

SkinGraft「使えない」はちょっと言いすぎでしたね。今のmodxには、WordPressやJoomla!などに見られる「簡単なサイトならサクっと入れてサクっと構築できる」お手軽感（アプリケーション層の使い勝手）が足りないと思い、その弱点を克服する一つの試みとして、私もSkinGraftを使いながら翻訳してみたんです。＾＾；

Quote from: にっく at May 26, 2009, 08:56 AM

SkinGraftですが、動作はするようです。開発中の日本語版Evo1.0.0jと0.9.6.3で動きました。
（僕は恥ずかしながら、このモジュールの存在を完全に見落としていました）

SkinGraftは「テンプレートインストーラー」兼「対応テンプレート生成用定義ファイル作成モジュール」だそうです。
SkinGraftレディなテンプレートは、ほぼWordPress感覚で一発インストールが可能。
モジュールの管理画面からテンプレート設定も可能でした。
オリジナルテンプレートセットを作成していますが、いまいちうまくいかず。
ここを確認したら、リソースとして配布できそうです。

日本語化ファイルと日本語マニュアルを作成したので、もしご入用があればお送りいたしますー。

ありがとうございます。ユーザインタフェース周りをもう少し改善すると良いものになると思うんですよね。使ってみた感想を正直に列記しますね。

１．skingraft自体のインストールがResource Wizard Moduleに依存しており、初心者がつまづく可能性が高い（マニュアルインストールも可能ですが、これは関係者が一様に認識してる問題点のようです）。
２．自動インストールは「テンプレート」と「チャンク」。スニペットはマニュアルで入れなければならない。
　　テンプレート変数も同梱できるようですがどこまでできるかは未評価です。
３．テンプレート適用後キャッシュをクリアしてないようで、マニュアルでキャッシュを消さないと適用結果が確認できない。
４．スキンのアンインストールのインタフェースが分かりづらい（編集に入ってから消す。消せないものもある）。
　　（抱き合わせでインストールしたチャンクやテンプレート変数はどうなるのか？）
５．テンプレートの作成画面と編集画面の操作性に難があり、パッケージの制作作業の負荷が高そう。
６．モジュールの画面デザインが独自仕様。DocumentManagerのようにコアと一体感のあるデザインが望まれる。

にっくです。どうも、お久しぶりです。

Quote from: sama55 at May 26, 2009, 03:08 PM

１．skingraft自体のインストールがResource Wizard Moduleに依存しており、初心者がつまづく可能性が高い（マニュアルインストールも可能ですが、これは関係者が一様に認識してる問題点のようです）。
２．自動インストールは「テンプレート」と「チャンク」。スニペットはマニュアルで入れなければならない。
　　テンプレート変数も同梱できるようですがどこまでできるかは未評価です。
３．テンプレート適用後キャッシュをクリアしてないようで、マニュアルでキャッシュを消さないと適用結果が確認できない。
４．スキンのアンインストールのインタフェースが分かりづらい（編集に入ってから消す。消せないものもある）。
　　（抱き合わせでインストールしたチャンクやテンプレート変数はどうなるのか？）
５．テンプレートの作成画面と編集画面の操作性に難があり、パッケージの制作作業の負荷が高そう。
６．モジュールの画面デザインが独自仕様。DocumentManagerのようにコアと一体感のあるデザインが望まれる。

僕が触った印象と、若干違う感じですね。以下、僕の感想です。

１・インストールはマニュアルで可能でした。Resource Install Wizard自体は、僕が気づいたときにはダウンロードできなかったため未検証です。使っていません。手作業でインストールする手間はありましたが、そんなに苦痛ではありませんでした。

２・おっしゃるとおり「デフォルトで使用していないスニペットは手作業でインストール」が必要のようですが、デフォルトのテンプレートの場合は必要ありませんでした。ただし、SkinGraftレディなテンプレートでも、書き方によっては「WayFinderが必要です」などと、既存スニペットの有無を確認するメッセージが出てきます。この辺はSkinGraftの甘いところかも

３・これはそのとおりです

４・これもそのとおりですが、WordPressのテンプレートインストールにおいても、基本は「テンプレートファイルをFTPでアップしたらインストール完了」「FTPでテンプレートフォルダごと削除すればアンインストール完了」なので、問題視するレベルの手間ではない気がする

５・まだ自分でパッケージ生成できていませんが、既存のSkinGraftレディのテンプレートを見ていると、単純に10行程度のskin.phpファイルを定義するだけです。それほどの負荷とは思えません。

６・うーん、これは個人レベルの感覚の問題だと思います。僕は可も不可も感じませんでした。

総じてブラッシュアップの余地はありますが「結構使えそうじゃん」というのが僕の印象です。

SkinGraftについて本家メンバーと話したのですが
・テンプレートを複数使うならともかく、一度運用が始まったらあまり使わない
ということで、本家内で低評価だったようです。このため、SkinGraftがあまり注目されなかったようです。

一方、初めてmodxを触る人は、そもそもテンプレートの入れ替えで詰まる人も多いと思うため、SkinGraftで簡単にテンプレートを入れ替えられるようでしたら有用だと思います。

WordPressの楽しさのひとつに「世界中のテンプレートスキンをあれこれ簡単に入れ替えられる」というのがあります。
実際楽しいのですが、よく見ると日本語環境では化けてたり、メニューが不完全だったりすることも多々あります。

それでも「あれこれ優れたデザインをとっかえひっかえするうちに、WordPressそのものの楽しさに引き込まれる」というメリットがあります。

modxでいえば、これはSkinGraftが担うべき役割だろうなと感じました。WordPressやMovabelTypeのインストールと比べると、そんなに手間の面において遜色ない気がします。

本家の評価は個人的にはあまり納得できず「このモジュール、結構有用じゃないか」というのが率直な印象です。

スキンを制作／提供する人は今のままでもよいですが、利用者（スキンなど作らない殆どの一般利用者）を第一に考えると、スキンの生成機能は削除するか見えないようにした方がよいと考えてます。余計な機能があることでこのモジュールの立ち位置が不鮮明で分かりづらいものになってると思うからです。本家での扱いが曖昧に推移したのは、この辺にも原因があるような気がします。

さらにもう一歩話を進めますと、スキンの制作は圧倒的な操作性を誇るドリやビルダーなどの市販オーサリングツールに任せ、同ツール内のテンプレートやライブラリをSkinGraftフォーマットに落とすプラグインが出てくれば、スキンを制作する人が自然と増えてmodxのシェアがアップするような気がします。

表が挿入できない

ドキュメントの編集でIE7、8のフルスクリーンで表が挿入できません。
Google Chrome 2.0 では本家版 0.9.6.3 ～ Evo 1.0J の通常サイズでも挿入できないようです。

よろしくお願いいたします。