今回の課題は、「eZ Publishの案件を成功させるベストプラクティス」となります。

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

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

3. CMS を理解する

4. CMS を理解する
● CMS とは？

5. CMS を理解する
● CMS とは？
●
コンテンツ管理システム

6. CMS を理解する
● CMS とは？
●
コンテンツ管理システム
●
なら、コンテンツとは？

7. コンテンツとは？
●
ウェブページ
●
ユーザ

8. コンテンツとは？
●
ウェブページ
●
ユーザ
●
… 製作側の視点

9. コンテンツとは？
●
クライアントからの視点なら

10. コンテンツとは？
●
商品
●
書籍
●
動物
●
イベント
●
航空券
●
設備
●
動画
●
。。。

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

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

13. ニーズを理解する
●
システムのニーズは？

14. ニーズを理解する
●
システムのニーズは？
●
仕様書でまとめられたニーズだけじゃない

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

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

17. eZ Publish を理解する

18. eZ Publish を理解する
● eZ Publish は CMS

19. eZ Publish を理解する
● eZ Publish は CMS
● でありながらフレームワーク（ CMF ）

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

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

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

23. eZ Publish を理解する
●
なんでも実装できます

24. eZ Publish を理解する
●
なんでも実装できます
●
だけど同じコストで実装でません

25. eZ に向いてる案件
●
進化するシステム
●
特殊な機能が必要なシステム
●
システム連動が必要なシステム
●
イントラネット

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

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

28. 必要機能をリストアップする
●
マルチサイト
●
多言語
●
ワークフロー
●
ユーザ組織
●
権限
●
コンテンツタイプ（コンテンツクラス）
●
。。。

29. ポイント
●
できるだけ汎用的にまとめる
●
機能をカテゴリわけする

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

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

32. コンテンツクラスの設計
●
クラスの切り分け
●
属性のデータタイプ
●
新データタイプが必要？

33. コンテンツ構造の設計
●
親子関係
●
関連関係
●
固定コンテンツ
●
運用コンテンツ
●
バーチャルコンテンツ
●
セクション

34. イベントサイトの例

35. 機能大盛サイトの例

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

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

38. ネイティブ機能
● eZ Publish には豊富な標準機能
● ドキュメントされてない機能もあります !?
●
ネイティブ機能はしっかりテストされています
●
だけどネイティブテンプレートに無駄と古い
コードが多い
● GUI や設定ファイルだけで使えるものが多い

39. カスタム機能
●
コンテンツクラスとテンプレートは必ず
● eZ Publish の標準コードを一切触らないでほと
んどの機能を実装できる
●
エクステンションベース
●
テンプレート言語も拡張できる！！
● eZ Publish API と eZ Components を使える

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

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

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

43. エクステンションの切り分け
●
汎用デザイン（再利用できる場合）
●
デザイン
●
機能
●
テンプレートオペレーター（マイクロ言語）

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

45. テンプレート
●
テンプレートオーバライド、
カスタムテンプレートビューと
セクションでテンプレートを分解する
●
＝＞再利用ができる
●
＝＞テンプレート数は減る
●
＝＞デバグはしやすい

46. 実装レベル
●
テンプレート
●
オペレーター
● PHP クラス
● ＝＞テンプレートで 5 行以上の再利用できるロ
ジックはオペレーターにする
● ＝＞できるだけ PHP クラスにコードを移す
●
＝＞実装が早い、デバッグは簡単、テンプレー
トはわかりやすい、可能性が広がる

47. ライブラリー
● eZ Components は使える！カスタム CMS まで
作れる
● eZ Publish の autoload 機能で外部ライブラ
リーを利用するのは簡単（ include 必要無い）
● API （ JSON 、 REST ）で外部システムと連動
するのも簡単

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

49. 設計ステップ 5
権限設計

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

51. まとめ

52. まとめ
● eZ の柔軟性と適応性をフールに使って、
開発時間を短くして
進化に対応するシステムを作れる
● ステップ 1 とステップ 2 はとても重要！
●
再利用できるエクステンションを作って、これ
からのプロジェクトをさらに早く

53. まとめ
●
開発側を忘れない、
”急げば回れ”
わかりやすさとデバッグは何よりも大事
●
運用側を忘れない、
できるだけ苦労させない（自動化）
できるだけ失敗させない（権限）
●
見る側を忘れない、
パーフォマンスはわすれない
キャッシュはしっかり設定するもの

54. 質問