モデルとかアソシエーションを

CIの機能で要る子、要らない子を列挙してみないか？
欲しい子もありで。

・・・考えてみたら、欲しい子、要らない子ばかりで
要る子がいなかった・・・orz

擬似構文　と　インプットフィルタ　はCIが一番シンプルで使いやすい

サイト内ナビゲーションリスト生成ヘルパがほしい。
ＣＩだけではないが。
コントローラーのディレクトリ内ファイル名を読み出してbaseurlにくっつければいいのかな。
でも全部出てくるのも困るからやっぱり手動か。
テンプレでの表示とカスタマイズはCMS的に管理画面からいじれれば一番ラクだな。
CSSや画像も含めて、まず専用の管理画面を自作するべきなのかもしれないな。

>>304

結局　凝ったナビにしようとすると
手打ちにならない？

普通のナビならCMSのほうが楽だけど

フレームワークをわざわざ使うということは、静的とか単一機能のサイトではなく、
ページコンテンツが日々どんどん更新され増えていく（と勘違いしている）ようなサイトが多いと思う。
そうなるとやっぱり、更新されたページ含めてサイト内ナビを自動で出したくなる。パンくずも出したい。

デザインのCSSや画像は、後戻りのない更新というより、素人管理者でも一発ですぐ元に戻せる「切り替え」という形にしたい。
新旧別内容の同名ファイル群をftpで切り替えるというのはこれも間違いの元で、稼動中の商用サイトに多用するのは危険。

まあ結局そこまでの機能が出来合いで欲しければExpressionEngineとやらを買え、ということなのかもしれないが。

客が勘違いしてるのだったらそこは客の要件を正すか、
ブログを使った方がいいんでない？

あと、ナビというのを漏れは勘違いしているのかもしれないが、増えるページというのは
「DBにデータが入る＆グルーピングされる＆管理画面から追加する」と思っているので、
ページリスト的なものを一つ作れば終わりかなあと思ってる
グルーピングされてるからパンくずも固定だし

（パンくずはセグメントとラベルの対応テーブルから引用するプラグインを作って
　テンプレに埋め込んで表示させてるけど）

話変わるが、ACLもユーザグループと権限の対応テーブルで制御してて、
メニューを非表示にしたり、直打ちされたら404を返すようにしている

ＣＩは「簡単で軽量」「10分でつくれる」という夢を見せてくれるけど、
実用で使うには、自前でpukiwikiやワードプレスやxoopsをつくるくらいのプランニングと実装が必要になるてこと。

つまり、ルーティングシステムから各ヘルパ関数までフルスクラッチで自作するよりは簡単で、
テンコ盛りの無駄機能に縛られるxoopsよりは圧倒的に融通が効いて軽量だな。

仕様はともかくサイト内ナビ・リンク管理機能を売り文句に加えればdreamweaver並に売れるｗ

はぁ・・・

もともとCIを含んだフレームワークは、
pukiwikiやxoopsなどを作るための
プログラム用のツールだろ。

サイト内ナビ・リンク管理機能とか意味不明だっつーのｗ

いずれにしても必要になるその機能を、
１．フレームワークの段階で<li>で出てくる程度のものを用意するか。
２．各現場プログラマーが自作するか。
３．デザイナーやコンテンツライター、素人管理者がしこしこ手打ちするか。
てこと。
まあ縄張り争いにもなるので結論は期待していないが。

スレ違いですまんが、
デザイナー様にはformの要素のnameの付け方ぐらい覚えて欲しいな。
name書かないとか""にしておくぐらいならDBテーブルのフィールドと
同じ名称をつけておくぐらいして欲しいよう

俺が出会ったフリーのデザイナーなんて上記ばっかりなのだが、
そういうものなの？

書いたら書いたで文句言うのが出てくる。
触らぬウンコにたたりなし。

>>311
文句言うなよ雑用係

スレ汚しすまそ

>>311
無理。

nameに書く名前はデザイナーが決めるものじゃないから。

いや、どうせ意味のないnameを書くぐらいだったら
被る部分は事前打ち合わせするぐらいの責任感は欲しいわけですよ

>>316
私が作ったデザインを使うときに
あなたが打ち合わせに来てください。

タグのidを全ファイルに適切に挿入するプログラムなんてプログラマー名乗る成人男子なら当然すぐ書けるんでしょ？

>>311

むしろ　HTMLすらまともに書けないプログラマーのほうが多い…

なんでもかんでも div や p とか

CIとは関係ないけど　FWでもヘルパの吐き出すHTMLが糞
っていうのはよくある

そりゃあHTMLは普通プログラマが書く所じゃないんだから普通だろ。
完全W3C準拠じゃないとダメとか言い出す潔癖症みたいなのまでいるしな。
それこそデザイナーの仕事。
プログラマはデザイナーの作った見た目だけで論理構造の破綻しているコードを手直ししてるんだから
デザイナーはプログラマの書いた表示上整ってるだけでHTML的に糞なコードを手直しすればいい。

けんかはやめて！

>>298
cakeのスレみたら
なんかthreadとかいうクラスあるみたいな
PHP自体がthreadセーフじゃないのに何がthreadなんだか
そんなセンスのないフレームワークなんかいいはずがない

CIも標準セッションがアレだから人のこと言えない罠・・・orz

ciはファンキーなんだよ
cakeはナンセンス

>>322
threadクラス？聞いたことないぞ。
思い込みじゃないのか？

よく見たらユーザが書いたコードの一部っぽいな

おまえなｗ

しかも、２ちゃんねるの「スレ」の意味の
スレッドじゃねーか。

FWがファンキーなら使い手もファンキーらしい

ciはファンキー＆ファンシー

おお！本の発売待ってました！
…てか、結構まだ先ですねorz

http://codeigniter.jp/archives/102
2008年6月9日「CodeIgniter徹底入門」が発売されます！
翔泳社より発売されます。徹底入門シリーズとして、約600ページの内容となります。
サンプルコードやレシピなど内容も充実しています。

DBのテーブル設計（MySQL）についてご意見をお聞かせください。

O/Rマッパーとか使ったことないんですけど、カラム名の命名は規則があった方がいいもんですか？

(1) id int型 auto_increment = 各テーブルの主キーのカラム名

(2) レコードのCRUDに関するデータを入れておくカラム名
insert_datetime datetime型
update_datetime datetime型
delete_datetime datetime型 (論理削除の場合にフラグとして使用)

>>330

セッションとかそういう
デメリットの部分をカバーしてくれてるなら買うが・・

そうでなければ買う意味なさそうだな

そんなイレギュラーな使い方の解説はないだろ

普通の使い方　解説されてもな・・・

正直セッションは何とかして欲しい

CakePHP使えば？

糞ルータのハック面倒くせー
セグメントベースって何なんだよ
ci以外にあんのかこんなの

普通の使い方ならオンラインドキュメントで充分だろう。

痒いところに手が届く解説が欲しいな。

本が出る→認知度アップ→仕事で使ってもお客さん安心→ウマー

ちいたんも本が出たら…(・∀・)

>>339
あったよ。
http://www.amazon.co.jp/s/ref=nb_ss_gw?__mk_ja_JP=%83J%83%5E%83J%83i&url=search-alias%3Daps&field-keywords=%82%BF%82%A2%82%BF%82%E1%82%F1

>>339-340
この流れは読めた。

>>340
おお！

ちいちゃんとぷろぐらまーｗｗｗｗｗｗ(ﾉ∀`)

みなさんＣＩで何つくってるの？会社案内？

>>343
ショッピングカートとかCMSとか。
あちこち独自ライブラリで拡張しまくりだけど。

CIは独自フレームワークを作るためのフレームワークという感じ。

>>344
同じく。
自前でフロントコントローラ作るのが面倒だからプロジェクト毎に特化したCIライブラリ拡張してる。
って使い方するならCIは便利だと思う。

他の人はどうなの？

>>345

同じく。つか、これこそFWだと思う。

今後は他のFWから依存しないライブラリを
パクって統合してみる予定。キメラ的な感じ。

aso

ばかだなぁｗ

フレームワーク意味ないじゃないかｗ

>>348
じゃあ、フレームワークの意味をなくさない程度の
使い方ってものを講釈願おうか

汎用的な部分は誰が作っても同じような構成になる。
独自のライブラリはなるべく使わない。