ブログ

LanguageManager

2010-05-18T15:44:24+09:00

■XCube_LanguageManager
(core/XCube_LanguageManager.class.php)

●メンバ変数
protected mLanguageName
protected mLocaleName

●メソッド
・prepare()
初期化を行う。

・loadGlobalMessageCatalog()
グローバルメッセージカタログを取得する

・loadModuleMessageCatalog($moduleName)

・loadThemeMessageCatalog($themeName)
???

●アクセサ
・setLocale($locale)
・getLocale()
・setLanguage($language)
・getLanguage()

●protected
・getFallbackLanguage()
フォールバック用言語(英語)を得る

■Legacy_LanguageManager
(modules/legacy/kernel/Legacy_LanguageManager.class.php)

●追加メソッド

・loadPageTypeMessageCatalog($type)

・loadModuleAdminMessageCatalog($moduleName)
・loadBlockMessageCatalog($moduleName)
・loadModinfoMessageCatalog($moduleName)

定数名に長い識別子をつけると正しく認識されない

2010-05-16T23:10:00+09:00

モジュール開発
モジュールのコンフィグ設定の定数名に長い識別子をつけると正しく認識されない。

これはコンフィグ設定を保持している xoops_config テーブルのスキーマ定義が
conf_name は varchar(25)
conf_title は varchar(30)
になっているためである。

そのため定数名として 30文字以上の名前をつけると、一般設定画面でタイトルが表示されなくなる。

スキーマを無理矢理大きくするのが良いかも？

ALTER TABLE xoops_config MODIFY `conf_title` varchar(255) NOT NULL default ''

XoopsObject

2010-05-16T22:50:00+09:00

XoopsObjectはデータにアクセスする際のデータオブジェクトのインスタンスになるクラス

AbstractXoopsObject -> XoopsObject と継承している

・AbstractXoopsObject(純粋抽象クラス)
setNew()
unsetNew()
isNew()
initVar($key, $data_type, $default, $required, $size)
assignVars($values)
set($key, $value)
get($key)

・XoopsObject
フィールド変数を配列としてメンバ変数 vars に保持する。
フィールド変数は以下のプロパティ(実際には連想配列)を持つ
value
required
data_type
maxlength
changed
options

required や maxlength はDBのスキーマと関連する部分だが、このレベルで保持して管理するのが必須のものとは思わないが...
changed は意味は分かるが、cleanVars() で使うのはちょっと...
options はここにあるべきものではないかも...
getVar('show') や getVar('preview') というのもどうかなぁ...
dohtml,doxcode,dosmiley,... などがあるのはすでにUI部分がここに侵略していると言うことで...楽しくない感じ

フィールド変数の種類は以下の通り
XOBJ_DTYPE_STRING
XOBJ_DTYPE_TXTBOX
XOBJ_DTYPE_TEXT
XOBJ_DTYPE_TXTAREA
XOBJ_DTYPE_INT
XOBJ_DTYPE_URL
XOBJ_DTYPE_EMAIL
XOBJ_DTYPE_ARRAY
XOBJ_DTYPE_OTHER
XOBJ_DTYPE_SOURCE
XOBJ_DTYPE_STIME
XOBJ_DTYPE_MTIME
XOBJ_DTYPE_LTIME
XOBJ_DTYPE_FLOAT
XOBJ_DTYPE_BOOL

設計的にはデータ型なのかUI要素なのか分からないような項目 (TEXTBOX, TEXT, TEXTAREA) や微妙な項目(URL, EMAIL)などがあるのがしっくり来ないところ。
実装的にはフィールド変数の種類が増やせないような実装(オブジェクトではないから...)になっているのが厳しい。

フィールド変数をオブジェクトではなく連想配列で保持しているのはパフォーマンスを考慮してのことだろうか...(もしくは PHP4の頃のオブジェクトの扱い上の問題からか...)

D3 モジュールによる notification (2)

2009-05-30T22:50:00+09:00

D3 モジュールによる notificationからの続き

■(1) 通知一覧の名称が表示されない問題
notify_func を使わないやり方はシンプルで良いのだが、唯一問題がある。

それは通知一覧を見たときに、item_nameでコンテンツが特定されるコンテンツの名称欄が「無題」となってしまうことだ。

notifications の仕様では not_itemid にコンテンツを特定する ID を保存しておき、それを notify_func に渡してタイトルを取得するようになっているため、notify_func が存在しないと、「無題」と表示されることになる。

表示が「無題」となるのは良いことではないが、altsys が行ってくれる範囲ではこれで仕方がない。

そのうちに何とかしたいものだ。

■(2) 選択イベント更新後の飛び先が...
これはD3モジュールだからという訳ではないのだが
subscribe_from はファイル名で指定するため
アクションコントローラタイプのモジュールの場合、index.phpだけになってしまう。
そのため、item_name を指定した場合に意図したページに飛ばすことができなくなる。

たとえば、次のようなモジュールの構成の場合。
モジュールトップ index.php
コンテンツ index.php?action=view&pid=12
というようになっていたとして
index.php?pid=12
などのようにリダイレクトされてしまい、モジュールトップが表示されてしまう。
それだけならまだ良いのだが、モジュールトップにもイベント選択機能が付いていると、pid=12 のイベント選択項目も表示されてしまうのだ。

これはどうしたら良いのだろうね...

D3 モジュールによる notification

2009-05-25T16:50:00+09:00

D3モジュールに notification を実装する際の問題点

標準では mail_template を公開側から取得しようとするため、テンプレートが取得できない...

altsys-0.61以上に追加されている D3NotificationHandler を使えばOK

ただ、lookup_func による以下の変数の埋め込みはサポートされていない。


X_ITEM_NAME
X_ITEM_URL
X_ITEM_TYPE

というか


// Add some tag substitutions here
$tags = array();
// {X_ITEM_NAME} {X_ITEM_URL} {X_ITEM_TYPE} from lookup_func are disabled

となっているので敢えてなくしているようだ...

おそらく、triggerEventの第４引数に extra_tag を与えればすむことだからか。

そういう訳で、xoops_version.php の $modversion にも lookup_file, lookup_func は不要である。

しかし、これには少し問題がある...

D3 モジュールによる notification (2)へ続く

テンプレート変数

2008-11-29T23:40:00+09:00

■サイト関連
xoops_sitename
サイト名
xoops_slogan
サイト副題
xoops_pagetitle
ページタイトル

■テーマ関連
xoops_theme
テーマ名
xoops_imageurl
テーマurl
xoops_themecss
テーマCSS url

xoops_modulename

xoops_dirname

xoops_isadmin

xoops_banner

XCube_Identity, XCube_Principal と XoopsUser

2008-09-27T22:20:00+09:00

XCube_Identity, XCube_Principal はともに抽象クラス?
.NETフレームワークに似ている？

.NETフレームワークのロールベースセキュリティモデルについて

■XCube_Identity
ユーザ名と authenticationType を保持するクラス
・XCube_Identity()
コンストラクタ
・setAuthenticationType()
・getAuthenticationType()
・setName()
・getName()
・isAuthenticated()

■XCube_Principal
Principal は Identity を保持している。
・XCube_Principal(XCube_Identity $identity, String[] $roles)
コンストラクタ
Identity とロール名文字列配列で初期化される
・getIdentity()
XCube_Identity を得る
・isInRole($rolename)
Principal がロール名で指定されたロールを持っているか？

------------------------------------------------------------
Legacy_Identity と Legacy_GenericPrincipal は XCLでの実装クラス

■Legacy_Identity extends XCube_Identity
XCLでのログインユーザの Identity
・Legacy_Identity(&$xoopsUser)
コンストラクタ
・getName()
$xoopsUser->get('uname')
・isAuthenticated()
true

■Legacy_AnonymousIdentity
XCLでの未ログインユーザの Identity
・isAuthenticated()
false

■Legacy_GenericPrincipal extends XCube_Principal
XCLでの Principal

------------------------------------------------------------

isInRole('Site.Administrator')
isInRole('Site.Owner')
isInRole('Site.RegisteredUser')

isInRole('Module.legacy.Admin')
isInRole('Module.user.Admin')

XCL [2.1.5] のレンダリング

2008-09-20T23:00:00+09:00

XCL ではレンダリングエンジンに smarty を使用している。

■RenderSystem
XCubeRoot が保持する RenderSystem によってレンダリングが実行される。
RenderSystem は公開側と管理側で分かれており、settings/site_default.ini に定義されている。


[RnderSystem]
Legacy_RenderSystem
Legacy_AdminRenderSystem

がそれぞれ使われる

RenderSystem は
XCube_Root::getRenderSystem($name)
で取得できる。
XCube_Root は指定された RenderSystem がまだ存在しなければ、siteConfig の情報を使って作成する。

■Legacy_XoopsTpl extends XoopsTpl
Smarty を継承したテンプレートエンジン
RenderSystem に保持されている。
RenderSystemは、レンダリングを XoopsTpl に依頼する。

■RenderTarget
レンダリングする対象
レンダリング結果を保持する？
俗に言う(？) $render がこれである。


XCUBE_RENDER_TARGET_TYPE_BLOCK
XCUBE_RENDER_TARGET_TYPE_MAIN
XCUBE_RENDER_TARGET_TYPE_THEME
XCUBE_RENDER_TARGET_TYPE_BUFFER

$render->getAttribute('legacy_buffertype')

といった種類がある。

RenderTarget は
Legacy_RenderSystem::createRenderTarget($type, $option)
で作成される。


XCUBE_RENDER_TARGET_TYPE_BLOCK
 => XCube_RenderTarget
XCUBE_RENDER_TARGET_TYPE_MAIN
 => Legacy_RenderTargetMain
XCUBE_RENDER_TARGET_TYPE_THEME,XCUBE_RENDER_TARGET_TYPE_BUFFER
 => XCube_RenderTarget

XCL User 関連

2008-09-17T23:40:00+09:00

XCL [2.1.5] ${Dirname}_Module に関する考察 (その２)

2008-09-14T23:50:00+09:00

というわけで、mModuleConfig の取得をオンデマンドに行う実験をしてみた。

■config 取得を遅らせる実験
まずは Legacy_AbstractModule の mModuleConfig を private に変更する。
コンストラクタでの mModuleConfig 取得をやめる。
getModuleConfig() を修正し、mModuleConfig を取得していなくてconfig が存在すれば、mModuleConfig を取得するようにする。
setModuleConfig() はprivate にする。

■結果
一応それなりに動いているようだ。
カレントモジュールについては、互換性の関係 ($GLOBALS['xoopsModuleConfig'])ですぐに取得してしまうから、動作に支障はないと思う。
カレントでないモジュール（管理側だけということだが）では明らかに getModuleConfig の呼び出しはほとんどなく、事実 config へのSQLが激減した。

■結論
この程度のオーバーヘッドであれば、公開側でも ${Dirname}_Module をそれぞれのモジュールについてインスタンス化してもかまわないのではないだろうか。

もちろんパフォーマンスの問題はSQL問い合わせの量だけの話ではないが...

■宿題
個人的には modules への度重なる問い合わせが気になる...
これは局所的な話では改善できないが、モジュールマネジャーの導入で解決が図れるように思う...
でもちょっと手を入れる範囲が大きすぎるね....