eZ Publish 設計ベストプラクティス〜案件成功の道〜

   

ご挨拶

● サニエ　エリック● twitter/identica : @ericsagnes● サイト http://clina.jp/

   

CMS を理解する

   

CMS を理解する

● CMS とは？

   

CMS を理解する

● CMS とは？● コンテンツ管理システム

   

CMS を理解する

● CMS とは？● コンテンツ管理システム● なら、コンテンツとは？

   

コンテンツとは？

● ウェブページ● ユーザ

   

コンテンツとは？

● ウェブページ● ユーザ● … 製作側の視点

   

コンテンツとは？

● クライアントからの視点なら

   

コンテンツとは？

● 商品● 書籍● 動物● イベント● 航空券● 設備● 動画● 。。。

   

管理とは？

● 目的があるから管理をする● その目的はシステムそれぞれ

   

管理の目的

● コンテンツを見つけやすくする● コンテンツ読み込みにアクセスを制限する● コンテンツ書き込みにアクセスを制限する● 認証ワークフローを設定する● 製作ワークフローを設定する● コンテンツを構造化する● コンテンツを簡単に追加できる● など

   

ニーズを理解する

● システムのニーズは？

   

ニーズを理解する

● システムのニーズは？● 仕様書でまとめられたニーズだけじゃない

   

ニーズを理解する

● 三手先を読む● これからのニーズを予想する● 新機能が開発しやすい● 冗長化に対応できる● 組織変更に対応できる● 。。。

   

ニーズを理解する

● クライアントのニーズは変わるもの！● 仕様変更は覚悟の上！● 適応性と柔軟性は神の贈り物！

   

eZ Publish を理解する

   

eZ Publish を理解する

● eZ Publish は CMS

   

eZ Publish を理解する

● eZ Publish は CMS● でありながらフレームワーク（ CMF ）

   

eZ Publish を理解する

● eZ Publish は CMS● でありながらフレームワーク（ CMF ）● 標準機能が多い！（多すぎ？）

   

eZ Publish を理解する

● eZ Publish は CMS● でありながらフレームワーク（ CMF ）● 標準機能が多い！（多すぎ？）● 柔軟性豊か！

   

eZ Publish を理解する

● eZ Publish は CMS● でありながらフレームワーク（ CMF ）● 標準機能が多い！（多すぎ？）● 柔軟性豊か！● でもドキュメントが少ない。。。（日本語だとほぼない）

   

eZ Publish を理解する

● なんでも実装できます

   

eZ Publish を理解する

● なんでも実装できます● だけど同じコストで実装でません

   

eZ に向いてる案件

● 進化するシステム● 特殊な機能が必要なシステム● システム連動が必要なシステム● イントラネット

   

eZ に向いてる案件

● 進化するシステム● 特殊な機能が必要なシステム● システム連動が必要なシステム● イントラネット● コーポレートサイトは eZ Webin で秒殺

   

設計ステップ１必要機能をリストアップする

   

必要機能をリストアップする

● マルチサイト● 多言語● ワークフロー● ユーザ組織● 権限● コンテンツタイプ（コンテンツクラス）● 。。。

   

ポイント

● できるだけ汎用的にまとめる● 機能をカテゴリわけする

   

設計ステップ 2サイト構造

   

コンテンツクラスの設計

● とても大事なステップ！● パフォーマンス、運用、適応性に影響する● システムの基盤になる

   

コンテンツクラスの設計

● クラスの切り分け● 属性のデータタイプ● 新データタイプが必要？

   

コンテンツ構造の設計

● 親子関係● 関連関係● 固定コンテンツ● 運用コンテンツ● バーチャルコンテンツ● セクション

   

イベントサイトの例

   

機能大盛サイトの例

   

ポイント

● 運用の負担をできるだけ下げる● simple is best!● 関連属性を有効的に使う● セクションでコンテンツクラスを再利用● 自動化できるものは自動化する！

   

設計ステップ 3ネイティブ機能とカスタム機能

   

ネイティブ機能

● eZ Publish には豊富な標準機能● ドキュメントされてない機能もあります !?● ネイティブ機能はしっかりテストされています● だけどネイティブテンプレートに無駄と古いコードが多い

● GUI や設定ファイルだけで使えるものが多い

   

カスタム機能

● コンテンツクラスとテンプレートは必ず● eZ Publish の標準コードを一切触らないでほとんどの機能を実装できる

● エクステンションベース● テンプレート言語も拡張できる！！● eZ Publish API と eZ Components を使える

   

ポイント

● カスタム機能はコストかかります● できるだけネイティブ機能で実装する● カスタム機能は汎用に作って、再利用と機能変更を楽にする

   

設計ステップ 4エクステンション設計

   

エクステンションでできる事

● テンプレート、デザイン● 設定● 翻訳● テンプレート言語拡張● カーネル機能オーバーライド！● ほぼすべての標準機能を上書きできます

   

エクステンションの切り分け

● 汎用デザイン（再利用できる場合）● デザイン● 機能● テンプレートオペレーター（マイクロ言語）

   

エクステンションの切り分けの例

   

テンプレート

● テンプレートオーバライド、カスタムテンプレートビューとセクションでテンプレートを分解する

● ＝＞再利用ができる● ＝＞テンプレート数は減る● ＝＞デバグはしやすい

   

実装レベル

● テンプレート● オペレーター● PHP クラス● ＝＞テンプレートで 5行以上の再利用できるロジックはオペレーターにする

● ＝＞できるだけ PHP クラスにコードを移す● ＝＞実装が早い、デバッグは簡単、テンプレートはわかりやすい、可能性が広がる

   

ライブラリー

● eZ Components は使える！カスタム CMS まで作れる

● eZ Publish の autoload 機能で外部ライブラリーを利用するのは簡単（ include 必要無い）

● API （ JSON 、 REST ）で外部システムと連動するのも簡単

   

ポイント

● 修正とデバッグを忘れない！● 有効的にエクステンションをわける● テンプレートはできるだけ簡単に● eZ Components や外部ライブラリは使う● 再利用できそうなエクステンションは再利用しやすい様に作る

   

設計ステップ 5権限設計

   

ポイント

● ロールは組み合わせるもの！● 再利用できるロールは再利用します● セクションとサブツリー制限を有効的に使う● 匿名ユーザは複数できます● ユーザには必要以上な権限をあげません● ロールはユーザグループにも、ユーザ単独でつけれる

● 一つのユーザは複数のグループに属する可能

   

まとめ

   

まとめ

● eZ の柔軟性と適応性をフールに使って、開発時間を短くして進化に対応するシステムを作れる

● ステップ 1 とステップ 2 はとても重要！● 再利用できるエクステンションを作って、これからのプロジェクトをさらに早く

   

まとめ

● 開発側を忘れない、”急げば回れ”わかりやすさとデバッグは何よりも大事

● 運用側を忘れない、できるだけ苦労させない（自動化）できるだけ失敗させない（権限）

● 見る側を忘れない、パーフォマンスはわすれないキャッシュはしっかり設定するもの

   

質問