ブログ - 最新エントリー
(未確認)
管理者ユーザで試していると、テーマ選択などが正しくない場合にうまく機能しないことがある?
管理者ユーザで試していると、テーマ選択などが正しくない場合にうまく機能しないことがある?
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')
.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')
(その2から続いています)
■バリデーションの順番を制御したい...
さて、その2までで無事カスタマイズできたわけだが、ちょっと気になることがひとつ。
それは、required チェックの順番の問題。
■バリデーションの順番を制御したい...
さて、その2までで無事カスタマイズできたわけだが、ちょっと気になることがひとつ。
それは、required チェックの順番の問題。
■_commonPrepareRender
_commonPrepareRender()
はブロックやメイン、テーマのレンダーごとに毎回呼ばれるが、mXoopsTpl に変数をセットしているので、一度セットすれば十分なのではないのだろうか?
内容的にも、不変なもののように見えるが...
RenderTarget で上書きされた場合のことを考慮しているのだろうか?
そうかも...
とはいえ、ちょっと効率が気になる...
■RenderTargetにアサインされた変数
ブロックの場合、RenderTargetにアサインされた変数は、XoopsTpl にコピーされ、レンダリング後 XoopsTpl から消去される。
しかし、メインブロックの場合は、レンダリング後に消去されていないように思える...
なので、theme.html でその変数を使用することができる?(未確認)
_commonPrepareRender()
はブロックやメイン、テーマのレンダーごとに毎回呼ばれるが、mXoopsTpl に変数をセットしているので、一度セットすれば十分なのではないのだろうか?
内容的にも、不変なもののように見えるが...
RenderTarget で上書きされた場合のことを考慮しているのだろうか?
そうかも...
とはいえ、ちょっと効率が気になる...
■RenderTargetにアサインされた変数
ブロックの場合、RenderTargetにアサインされた変数は、XoopsTpl にコピーされ、レンダリング後 XoopsTpl から消去される。
しかし、メインブロックの場合は、レンダリング後に消去されていないように思える...
なので、theme.html でその変数を使用することができる?(未確認)
XCL ではレンダリングエンジンに smarty を使用している。
■RenderSystem
XCubeRoot が保持する RenderSystem によってレンダリングが実行される。
■RenderSystem
XCubeRoot が保持する RenderSystem によってレンダリングが実行される。
以前ユーザ登録画面のカスタマイズをHackで対応してみた。「ユーザー登録画面のカスタマイズ」
今回はプリロードを使ってHackなしで対応してみる。
以下は [XCL 2.1.4] [XCL 2.1.5] で試してみたもの...
今回はプリロードを使ってHackなしで対応してみる。
以下は [XCL 2.1.4] [XCL 2.1.5] で試してみたもの...
■${Dirname}_Module の役割
XCL では modules/${dirname}/class/Module.class.php に
class ${Dirname}_Module extends Legacy_AbstractModule (or Legacy_ModuleAdapter)
というクラスが定義されている。
XCL では modules/${dirname}/class/Module.class.php に
class ${Dirname}_Module extends Legacy_AbstractModule (or Legacy_ModuleAdapter)
というクラスが定義されている。