wiki:pne-openpne3-note
 ここの情報は古いです。ご理解頂いた上でお取り扱いください。

Version 68 (modified by tejimaa, 12 years ago) (diff)

--

TOC

OpenPNE3ノート

レビュー機能

3.0では現在のレビュー機能を廃止しようと思います。 日記、小窓などを組み合わせることで、同等以上の機能を実現します。

レビューの新規登録

URL2CMD

レビューは各外部サイトからURL2CMDによって新規登録します。

レビューの閲覧【個別】

日記

プロフィール(メンバー・コミュニティ)

トピック

レビューの閲覧【一覧】

小窓リスト

小窓ランキング

PHPフレームワークの選定

参考情報

IBM developerWorksの比較記事

http://www.ibm.com/developerworks/opensource/library/os-php-fwk1/ http://www.ibm.com/developerworks/opensource/library/os-php-fwk2/ http://www.ibm.com/developerworks/opensource/library/os-php-fwk3/ http://www.ibm.com/developerworks/opensource/library/os-php-fwk4/ http://www.ibm.com/developerworks/opensource/library/os-php-fwk5/

CakePHP

概要

Ruby on Railsを強く意識

  • 活発でフレンドリーなコミュニティ
  • 柔軟なライセンス
  • PHP4 と PHP5 での互換性
  • データベースと連携し、クエリを簡略化するための CRUD が統合済み
  • アプリケーションの Scaffolding(足場組み)
  • モデル ビュー コントローラ (MVC) アーキテクチャ
  • 見栄えのよいカスタム URL を実現するリクエストディスパッチャー
  • バリデーションが組み込まれている
  • 高速で柔軟なテンプレート機能 (PHP 構文。各種ヘルパーが付属)
  • AJAX, Javascript, HTML フォームなどのための各種ビューヘルパー
  • セキュリティ、セッション、リクエストなどを処理するコンポーネント
  • 柔軟なアクセスコントロールリスト
  • データのサニタイズ
  • 柔軟なビューのキャッシュ
  • Webサイトのサブディレクトリでも動作。Apache はまったくいじらなくてよいか、わずかな設定のみ。

ZendFramework

足場機能(scaffold)

  • いまのところ見あたらない

ORマッピング

あまり激しくはやらないみたいだ

http://framework.zend.com/manual/ja/zend.db.select.html

$select = $db->select()
    ->from( ...テーブルとカラムを指定します... )
    ->where( ...検索条件を指定します... )
    ->order( ...ソート条件を指定します... );

フィールド名に対して規約での縛りがあまり無い。その代わりリレーションを自動で決定する機構も無い?

この方法は、動的にSELECTを変えたいときに使うそうだ

SQL書かないようにするには下記の方法か?

http://framework.zend.com/manual/ja/zend.db.table.html

symfony

プロジェクト支援

  • テーブル作成、プロジェクトビルド、など支援プログラムがある

MVCモデル

DB抽象化概要

  • 【symfony】ちょっと設定記述が多いかな、と思った。特に複数テーブルの処理では

DB構築

  • 【symfony】YAML形式で記述して、自動テーブル構築、抽象化してそう

リレーションの処理

  • 【symfony】$entory->getFeed()->getName()の用にリレーションをたどれる 1:多 ->getFeeds() 多:1 ->getFeed() の用に処理する

キャッシング

CodeIgniter?

  • DB抽象化されていて、PostgreSQL MySQL SQLiteがシームレスに利用できる?
    • yes
  • 携帯は挙動が特殊なので、フレームワークでカバーできるか?
    • 拡張すれば可能
  • Smartyテンプレートを使用できるか?(もしくは置き換えるに値する素敵なエンジンか?
    • 拡張すれば可能(Wikiに非公式ライブラリ有)
  • パフォーマンスが劣化しないか?
    • たぶん yes。Web上に公開されているベンチマークでは最も高速
  • ドキュメントが充実しているか?
    • 完全なドキュメント有
  • 今後サポートが継続されそうか?
    • yes(企業が開発している)
  • 国際化対応の機構が組み込まれているか?
    • yes(但し、非常に単純。WikiにGettext対応の非公式ライブラリ有)
  • OpenPNE2系からの移行に大きな負荷がかからないか?
    • 書き直しなのでどんなフレームワークでもある程度負荷はかかると思われます
  • トレンドなのでRailsをある程度意識していて欲しい
    • Active Record など意識されてます
  • PHP5限定のフレームワークでOK
    • 4/5とも OK

開発スケジュール

  • 【現在】仕様策定、アイデア
  • 【2008/02/29】仕様決定
  • 【未定】開発XX
  • 【未定】ベータ
  • 【未定】リリース

OpenPNE3で実現する内容

外部フレームワークを導入

外部フレームワークを導入して、プログラミング全体の構造を規定する。

http://trac.openpne.jp/wiki/pne-framework

ここで検討中。

プロジェクトチケット milestone=OpenPNE3.0

No results

OpenPNE3的なチケット keywords=openpne3

OpenPNE3.0で正式決定したわけでは無い物の、OpenPNEなチケットを集めます。

自由にkeywords=openpne3と編集してください。

#151
SNS同士のつながりを作る
#1131
バナー、インフォメーション欄、テンプレート挿入、HTML挿入の仕様を一本化する

どのInterSNS機能の実現するか?

最低1つ以上のInterSNS機能を実現する。

テンプレート構造の見直し

フルCSS化をめざしテンプレート構造を再構築する。

どこまで構造を洗練させるか?

  • 関数名を何とかしたい
    • フレームワーク導入に伴って、 xx4yy => getXXXに変えるかな?
  • 命名規則も決めたい

後方互換性の維持レベルをどうするか?

  • OpenPNEAPIで提供されているぐらいはほしい
  • OP関数は供給したい、関数名は変わっても同等以上の機能は維持したい

PNEBIZを一般モジュールレベルに切り離す

他のモジュールを取り込みやすくするために、PNEBIZ単独で特別扱いすることはやめる。

非HTTPベースで呼ばれるプログラムの扱い

http://sc.pne.jp/200801291512.png

非HTTPで呼ばれるプログラムは、API経由にして極力小さくする。 特にDBは呼ばせないようにする。

仕様

なぜか切り捨てられている機能

レビューが 切り捨てられると V2からV3に移行できない すくなくとも 標準のv2に現存する機能は V3で実現すべきだと思う。

URLスタイル

c_admin_request
c_admin_request_confirm
c_edit
c_edit_delete_c_commu_confirm
c_edit_member
c_edit_member_delete_c_commu_member
c_invite
c_join_commu
c_join_commu_2
c_join_err_already
c_join_err_wait
c_join_request
c_leave_commu
c_member_list
c_send_message
c_sub_admin_delete
c_sub_admin_request
c_sub_admin_request_confirm
c_taikai_err_admin
c_taikai_err_no_member
f_com_list_common
f_intro_delete_confirm
f_intro_edit
f_invite
f_message_send
f_message_send_confirm
f_show_image
fh_com_list
fh_comment_list
fh_delete_comment
fh_friend_list
fh_friend_list_delete_c_friend_confilm
fh_intro
h_access_block
h_com_add
h_com_add_confirm
h_com_comment_list
h_delete_diary
h_delete_ktai
h_free_page
h_friend_review_list
h_googlemap
h_ktai_delete_end
h_manage_friend
h_prof
h_regist_address
h_regist_prof
h_regist_prof_confirm
h_reply_message
h_set_public_flag_all_confirm
h_taikai_confirm

データ構造

  • メンバー
    • Memberクラス
    • membersテーブル
  • フレンドリンク(メンバーリンク)
    • MemberLinkクラス
    • memberlinksテーブル
  • コミュニティ
    • Communityクラス
    • communitiesテーブル
  • コミュニティトピック
    • CommunityTopicクラス
    • community_topics
  • message
  • event
  • event_topic
  • diary
  • diary_comment
  • permission

OpenPNE本体はHTTPリクエストレスポンスに特化

現在RSS デイリーメール mail.php などは単純なリクエストレスポンスモデルでは動いていない。 これをすべてHTTPのリクエストレスポンスモデルに書き換える。

  • CRON=>HTTPClient=>httpリクエスト=>OpenPNEモジュール
  • mail.php=>HTTPClient=>httpリクエスト=>OpenPNEモジュール
  • pop3mail.php=>HTTPClient=>httpリクエスト=>OpenPNEモジュール

メモ

フレームワークメモ

手嶋は WebObjectsが好きだった http://www.apple.com/jp/webobjects/ いずれRuby版OpenPNEも作りたいし、Railsを意識した作りがいいな。

ActiveRecord説明

http://www.railsenvy.com/2007/8/8/activerecord-tutorial

11/3勉強会メモ

OpenPNE3
■後ろ向き(後方互換性を無視できる)
・フレームワーク
・テンプレートを変える(FULLCSS化)

■前向き(InterSNS)
・人2SNS(複数のSNS)
    ・MySNS(MyPNE)

・SNS2SNS2アプリ(SNSメンバー限定Twitterみたいな)
    認証情報を外部アプリに払い出す(MasterPNE、OpenID、OpenSocial)
    貸し会議室、スターバックス(ネーミングライツを取ろう)

・SNS2SNS
    ・OpenPNE2OpenPNE
    ・mixi2PNE
    ・GREE2PNE
    ・モバゲー2PNE

※具体的に
北海道SNSと千葉SNSを交流

1.各SNSのメンバーのみが参加出来る、特設会場(Twitter)を作成して、そこで限定的に交流できる。(プロジェクト的、制限)

2.どんなSNSに入っていてもいいから、サッカーコミュニティに入っている人たち、横串でコミュニケーションできる。(出会い、発見、つながりを広げる)

・イベントは公開してもいいよね

3.6次の隔たり、LinkedInのOpenPNE版
※PNEMonsterで出来ないか?
異業種交流会
カルチャークラブ
飲み会
バー、クラブ
■h_homeから始まらない、SNS
----------------------------------------------
4.PNEMonster
・浮気調査(mixiで、離婚の切り札、作れます)
・SNSの盛り上げに使う(よねすけ、酢鶏)

PNEMonsterはOpenPNE3とは切り離して考える

・Appli2SNS(MasterPNE)

スタンドアローンSNSが、InterSNSに

1/15 国際化・フレームワーク勉強会メモ

https://trac.openpne.jp/svn/OpenPNE_specification/trunk/3.0/20080115_【3.0】フレームワーク・国際化.mm

http://sc.pne.jp/XXXXXXXXXXXX.png

WikiInclude(DIRECTORYNAVI)?