カスタムフィールドの実装
この件については、管理画面内の機能についてということなので、プラグインではなく、コアの側である一定のサポートができると思います。ただし、セキュリティーリスクの増大をほとんど伴わない範囲内でということになるかと思います。（逆に言うと、通常ページの表示部分の機能拡大については、なるだけプラグイン側で行うというのが理想になると思います。）
もう一つ考慮すべき事項として、Jeans CMSでは、管理画面もスキンで構成されているということです。デフォルトでは、skins/adminが選択されていますが、これの派生スキンを用意し、edititem.incだけを書き換えて利用するなどの方法も取れるので、そのあたりのことも考えてデフォルトの管理画面を構築してゆきたいです。
●自由に選べる入力インターフェイスについて
ソースコードを追ってみると（skins/admin/templates/forminput.inc）、現在のところ、text, yesno, textarea, selectをサポートしています。selectでは、grouplist, skinlist, adminskinlist, languagelist, editorlist, mediamanagerlistをサポートしています。あと、エキストラにhiddenの属性をつけることができるようになっています。この仕様は、Nucleusのプラグインオプションの仕様から持ってきています。
これをもう少し拡張しようという考え方でよいでしょうか？例えば、radioの実装などは、selectとほとんど代わらずできると思います。styleについては、jeans_config_descに一つカラムを追加するのが一つの考え方です。カレンダーＵＩなどの利用は、それ用のプラグインを呼び出すためのイベントの実装という形がすっきりするかもしれません。あと、例えば数値だけの場合などは、JavaScriptでのチェックルーチンの導入を考えていました。
●出力フィルター
ここは、セキュリティーの問題を生み出さない範囲で考えたいところです。例えば、htmlentitiesの処理などは慎重に行いたいです。XSS対策としては、基本的に、htmlspecialchars/htmlentitiesの処理は、表示するときに行いたいと考えています。そういう意味で考えると、特定のタグで囲むというのも、難しいです。と言うのは、こういう形でデータベースに保存したデーターは、生のままで出力する必要があるからで、ここにXSSの問題がおき得る危険性がはらんでいます。ですので、タグの生成は、出力時に行うのを基本に考えたいです。
と、ここまで書いて気がついたのですが、もしかしたらDBへの保存はそのまま行って、それを出力するときに加工するという考えでしょうか？もしそうなら、それはJeansコアが行う仕事ではなく、それぞれのスキンに記述するべき内容のような気がします。スキンに記述するタグの種類を整備するという方向性になりそうです。
●既定値のセット
現在の仕様でも、規定値をセットすることができます。ただ、「今日の日付」などのセットはできないので、それができるようなプラグイン用のイベントを整備するのが良いと思います。
●既定のフィールドも同じように
ここは、派生スキンでedititem.incを上書きするというやり方以外でということでしょうか？
●紐づけについて
難しい問題ですね。かなり議論が必要なところだと思います。
forminput.incの内容を確認しました。これなら、少し目が慣れたら私でも実装追加のお手伝いができそうですね。
もしかしたらDBへの保存はそのまま行って、それを出力するときに加工するという考えでしょうか？
そうです。入力したデータは、特に理由がなければ入力したままでストアするのがよいと思います。スキン側の記述で対応する場合は、モディファイア的・・というのかな？修飾子をつけるような感じで実装できると分かりやすい気がします。そういうふうにすると、投稿内容だけでなく、プラグインの出力に対してもフィルター処理を加えることができるので汎用性が増すのではと。サイト名やブログ名に対しても処理できますね。
NucleusやJeansではプラグイン実装で可能で、自分もこの種のプラグインは業務を通じて案件ごとにいろいろ作りますが・・・少し面倒で管理が大変と感じるようになってきました。たいていの処理の本体は1行から数行程度で書けますが、プラグインを書くとなるとそうはいかないですよね。コンテンツ処理に特化した簡易の機能だと思うと分かりやすい気がします。
現在の仕様でも、規定値をセットすることができます。ただ、「今日の日付」などのセットはできないので、それができるようなプラグイン用のイベントを整備
イベント経由だと、少し遠回りで分かりにくい気がします。（自分がメリットに気付いてないだけというのもありますが）
value="<%data.hsc(value)%>" ここですよね。Jeansをまだよく理解してなくて適当なことを書くようですみませんが、value="<%php.eval(date(Y年m月d日))%>" みたいなのはどうでしょ？あまりきれいじゃないかな・・
コードとデザインをどう分けるかという事になると思います。処理のうち、簡単なものについては、dataクラスで実装されています。<%data()%>とか、<%data.hsc()%>などです。「htmlタグを無効にする 」については、<%data()%>が対応しています。エンティティ処理は、<%data.hsc()%>です。
「$value = (!empty($value)) ? $before . $value . $after : "" みたいな処理」については、<%ifnot.isempty(value)%><%data(before)%><%data(value)%><%data(after)%><%endif%>と記述すると、実装できます。
あと、勧められませんが、簡単な操作ならPHPじか書きできます。スキンに<?php ... ?>と記述すると、...の部分が実行されます。ただし、規約としてecho文は禁止です（XSS防止のため）。
正規表現での置換など、より高度な扱いについては、面倒でもプラグインを書いてもらったほうが良いように思います。Jeansのプラグインの多くは、こういった形でタグを記述するようなものになると予想しています。Nucleusで言うところの、テンプレート変数ですね。Jeansでは、<%jp.xxx.yyy%>のように書きます。プラグインに記述するコードは、jp_xxxという名のプラグインクラスでtag_yyy()メソッドを用意するだけです。
あくまで、コードとデザインは明確に分離する仕様で行きたいです。かなり初期のバージョンで、データベースに保存するタイプのスキンタグの実装を行っていましたが、デバッグがほとんどといってよいほどできなかったので、廃止しました。
折衷案としては、タグだけを記述するプラグインについては、tag_xxxメソッドだけを書けば他のメソッド（name()など）はまったく記述しなくても良いようにするということです。これは、ライブラリの仕様に似ています。
やりとりを通じてノウハウが深まるようで、面白いです。dataクラスに興味が出てきたので、こちらもあとで見てみます。
コードとデザインは明確に分離する仕様で行きたい
できれば<%if%>も使わずにすむといいなと個人的には思いますが、そうなると考え方がだいぶ変わってしまいますよね。
条件分岐はマシン語レベルでもあるものなので、<%if%>を完全になくすのはほぼ不可能かなと考えています。<%select%>を実装したので、それが活用できるシーンでは<%if%>の連続よりもデザインの見栄えが少し良くなるかもしれません。実際、Jeansコアで記述しているスキンでは、多用しています。
繰り返し処理に関しては、<%for%>, <%do%>, <%while%>といった機能を実装するつもりはありません。これは、<%blog%>などのスキンタグ（テンプレートを別途記述）で実装するべきものだからです。私にとってこの部分はNucleusの大きな魅力だったので、そのままJeansに受け継ぎました。
デザインとロジックの分離が目的ということであれば、複雑な<%if%>文記述を<%parsedinclude%>読み込みでパーツ化してしまうこともできますしね。
ちなみに<%phpinclude%>は最近よく使うようになりました。echo "(c)" . date("Y") くらいならこれで十分で。NP_LinkToSkinFilesを重宝してます。
たまにはこちらで機能要望してみます。（いいのですよね？）
NP_znItemFieldEXのようなカスタムフィールドをコア側の仕様で実装できるようになると嬉しいです。できれば、カスタムフィールドだけでなくitem(body)やitemtitleなどの既定のフィールドも多少のカスタマイズができればと。 以下、具体的な要望です。
●自由に選べる入力インターフェイス
普通のinput type=text以外に、テキストエリア・ラジオボタン・チェックボックス・プルダウンメニュー・ファイルアップロードなど。form要素の種類だけではなく、データの種類も考慮できると思います。たとえば同じテキストボックスでも、全角文字を許可するもの・しないものでは変わってきますし、数値だったら幅が狭めの右寄せ(style=text-align:right;)がよいですし。また、日時データを入力したい場合はテキストフィールドだけでなくカレンダーUIを使えたり、色情報をインプットしたい時はカラーピッカーライブラリを呼び出したり、そういうことができればと。
●出力フィルター
入力された値をそのまま出力するのではなく、フィルター加工を通します。たとえばエンティティ処理・全角半角変換・特定のタグで囲む・日付の書式を変換する、などです。「特定のタグで囲む」というのは、特に画像の扱いなどで重要です。たとえば、そのアイテムで画像を投稿しなかった場合、src属性が空のimgタグを出力してしまうと困るからです。何も入力されなかった場合は何も出力しないのが理想です。
●既定値のセット
既定値を自由に設定できるとユーザフレンドリーです。大阪・京都・名古屋のうち「大阪」を既定値にするくらいは難しくないと思いますが、場合によっては「今日の日付」をセットしたいこともあると思います。
●既定のフィールドも同じように
item(title)を、場合によってはラジオボタンなどで３つある選択肢の中から選ばせるようにしたい。というケースもあるかと思います。また、item(more)は不要だから使わない。というケースも多いと思います。それなら全部をカスタムにしてもよさそうですが、既定のフィールドを定めておかないと標準的なノウハウが定着しないので・・
●紐づけについて
NP_znItemFieldEXはブログ単位でセットが紐付いてましたが、スキン単位のほうが分かりやすい気がします。ひとつのブログでひとつのスキンならNP_znItemFieldEX方式でもよいのですが。Nucleusの昨今のニーズを見る限り、同じブログ内でもページによってはスキンデザインを切り替えたいというケースはよくあると思います。
かなり工数の多い話になるはずので、ダメモト９割くらいな提案です。もし可能性がありそうならよろしくお願いします。