私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレPHP上級者が集まるスレ
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
スレ違いだったらすみません。
PHPDocumentorでチュートリアルを生成すると文字化けが起こるんですけど、どなたか解決方法を知りませんか?
文字化けというより、不正な文字を「?」に置き換えてる感じで、日本語が全部「??????」で出力されます。
チュートリアル以外のドキュメントは文字化けを起こさないのですが。。。
PHPDocumentorでチュートリアルを生成すると文字化けが起こるんですけど、どなたか解決方法を知りませんか?
文字化けというより、不正な文字を「?」に置き換えてる感じで、日本語が全部「??????」で出力されます。
チュートリアル以外のドキュメントは文字化けを起こさないのですが。。。
>301
すみません、解決しました。。。
Setup.inc.php の 733行目 にあった $ret = utf8_decode($ret); をコメントアウトしたら解決しました。
お騒がせしました。
すみません、解決しました。。。
Setup.inc.php の 733行目 にあった $ret = utf8_decode($ret); をコメントアウトしたら解決しました。
お騒がせしました。
>Perl/shell 形式のコメント (#) は使用するべきではありません。
PEARのコーディング規約でこんなの見つけたんだけど。
何でいけないんだろう。
unix系OSでphp使ってる人には身近なコメントだと思うんだけど、
(#)使っちゃいけないっていうのはただ単にWin系もしくは
入門者の人が見慣れてないから使うなってだけかな?
べつにPEARのコーディング規約をリファレンスにする必要は無いと思うし、
嫌なら別の規約を使えばいい話なのはわかってるんだけど、
「PHPでshell形式はいけない物」みたいな風潮が広まちゃったら嫌だなって・・・。
PEARのコーディング規約でこんなの見つけたんだけど。
何でいけないんだろう。
unix系OSでphp使ってる人には身近なコメントだと思うんだけど、
(#)使っちゃいけないっていうのはただ単にWin系もしくは
入門者の人が見慣れてないから使うなってだけかな?
べつにPEARのコーディング規約をリファレンスにする必要は無いと思うし、
嫌なら別の規約を使えばいい話なのはわかってるんだけど、
「PHPでshell形式はいけない物」みたいな風潮が広まちゃったら嫌だなって・・・。
>>303
「#」と「//」の2種類のコメントを混在させてはいけないって所がコーディング規約的な意図でしょ
「#」と「//」の2種類のコメントを混在させてはいけないって所がコーディング規約的な意図でしょ
だね。
「するべきではありません。」っていうのがいかにも#をつかうのが良くないと言っているように見えるけど
多分must not beぐらいの意味だろう。
「するべきではありません。」っていうのがいかにも#をつかうのが良くないと言っているように見えるけど
多分must not beぐらいの意味だろう。
//を使わずに#に統一するなら問題はない。
初心者のことを考えて//に統一するのもよい。
初心者のことを考えて//に統一するのもよい。
$result = array();
for($request as $key1 => $value1){
for($value1 as $key2 => $value2){
for($value2 as $key3 => $value3){
$result[$key3][$key2][$key1] = $value;
}}}
こんなイメージな多次元配列の次元位置を入れ替える方法を考えています
多次元配列の次元数が固定されていれば、
上のようなやり方でも大体行けるのですが、
n次元だった場合のいいロジックってないでしょうか
for($request as $key1 => $value1){
for($value1 as $key2 => $value2){
for($value2 as $key3 => $value3){
$result[$key3][$key2][$key1] = $value;
}}}
こんなイメージな多次元配列の次元位置を入れ替える方法を考えています
多次元配列の次元数が固定されていれば、
上のようなやり方でも大体行けるのですが、
n次元だった場合のいいロジックってないでしょうか
function test($request) {
$result = array();
foreach ($request as $key => $value) {
if (is_array($value)) {
$result[$key] = test($value);
} else {
return array($key=>$value);
}
}
return $result;
}
$result = array();
foreach ($request as $key => $value) {
if (is_array($value)) {
$result[$key] = test($value);
} else {
return array($key=>$value);
}
}
return $result;
}
一度作った配列を構成しなおすというパターンはそうそう無いよね
最初に作る時にそうしておくか、使う時に対応するかのどっちかで大抵は済むし、
最悪でも最初に2種類構築すればいいし
最初に作る時にそうしておくか、使う時に対応するかのどっちかで大抵は済むし、
最悪でも最初に2種類構築すればいいし
パット見の思いつき。たわごと。
n次元てことは再帰だろーなーと思うけど
array_keys()使う感じでできんかな。
n次元てことは再帰だろーなーと思うけど
array_keys()使う感じでできんかな。
こういう質問出るって事は、お前らFW使ってないのか?
まぁ自作関数ライブラリがあれば足りるケースがほとんどではあるが。
まぁ自作関数ライブラリがあれば足りるケースがほとんどではあるが。
>>315
どういうこと?
どういうこと?
>>317
何がどうしったかぶりなの?
何がどうしったかぶりなの?
FWは作ってないが、ライブラリ群は作ってる
で、今バリデーションの案を抗争中な訳なんだが、
どんなソースコードになったら、見やすくて分かりやすいだろ?
$str = vali::post('text')->mbLength(0,256)->var();
みたいにJavaっぽく書けば、分かりやすいけど細かい設定は付けれない
$v_id = array('func'=>vali::alnum,'error'=>'どうたらこうたら');
$id = vali::post('text', $v_id);
と、Cake風の書き方すれば、細かい設定もしやすいからいろんな事が出来る
そんなわけで、どんなバリデーション作ったら使いたくなる?
で、今バリデーションの案を抗争中な訳なんだが、
どんなソースコードになったら、見やすくて分かりやすいだろ?
$str = vali::post('text')->mbLength(0,256)->var();
みたいにJavaっぽく書けば、分かりやすいけど細かい設定は付けれない
$v_id = array('func'=>vali::alnum,'error'=>'どうたらこうたら');
$id = vali::post('text', $v_id);
と、Cake風の書き方すれば、細かい設定もしやすいからいろんな事が出来る
そんなわけで、どんなバリデーション作ったら使いたくなる?
つくりかけ
var $VALIDATIONS = array(
'varname' => array(
'trim' => array(),
'ascii' => array(),
'unique' => array( '※すでに使われている名前です。'),
'blank' => array( '※必ずご記入ください。'),
'date' => array( '※正しい日時ではありません。'),
'range' => array(18,100, '※18から100の数字をご記入ください。'),
'length' => array( 0, 20, '※20文字以下でご記入ください。'),
'bytes' => array( 0, 40, '※40バイト以下でご記入ください。'),
'regex' => array('/^[a-z0-9\-\_]*$/i', '※英数字と -(ハイフン) _(アンダースコア) のみでご記入ください。'), //複数設定可??
'in' => array('OPTIONS', '※正しい選択肢ではありません。'), //複数または直接array??
'method' => array('model::method', '※正しい値ではありません。'), //うまいことやる!!
),
);
var $VALIDATIONS = array(
'varname' => array(
'trim' => array(),
'ascii' => array(),
'unique' => array( '※すでに使われている名前です。'),
'blank' => array( '※必ずご記入ください。'),
'date' => array( '※正しい日時ではありません。'),
'range' => array(18,100, '※18から100の数字をご記入ください。'),
'length' => array( 0, 20, '※20文字以下でご記入ください。'),
'bytes' => array( 0, 40, '※40バイト以下でご記入ください。'),
'regex' => array('/^[a-z0-9\-\_]*$/i', '※英数字と -(ハイフン) _(アンダースコア) のみでご記入ください。'), //複数設定可??
'in' => array('OPTIONS', '※正しい選択肢ではありません。'), //複数または直接array??
'method' => array('model::method', '※正しい値ではありません。'), //うまいことやる!!
),
);
>>320
だいたいそんな感じになると思うけど
>trim
入力値の評価と修正が一緒にあるのは気持ち悪いかも
>unique
それはどっかDBとか見に行かなきゃいけないわけで汎用的にならないんじゃ?
>date
年月日が別のフィールドに分かれてたら3つフィールド名指定できる?
>blank
別のフィールドの値がXの時だけ必須入力とかはblankかmethodで対応できる?
だいたいそんな感じになると思うけど
>trim
入力値の評価と修正が一緒にあるのは気持ち悪いかも
>unique
それはどっかDBとか見に行かなきゃいけないわけで汎用的にならないんじゃ?
>date
年月日が別のフィールドに分かれてたら3つフィールド名指定できる?
>blank
別のフィールドの値がXの時だけ必須入力とかはblankかmethodで対応できる?
>>trim
>入力値の評価と修正が一緒にあるのは気持ち悪いかも
なるほど。ちょっと考えてみる。ちなみに「ascii」も全角→半角変換のつもりw
>>unique
>それはどっかDBとか見に行かなきゃいけないわけで汎用的にならないんじゃ?
まーねー。確かに規約で縛りすぎるのも気持ち悪い。しかし、どう代替しようか。
>>date
>年月日が別のフィールドに分かれてたら3つフィールド名指定できる?
柔軟な日時クラスがあるので、$varnameはymdのarrayでもsqlでもatomでもなんでもおk
>>blank
>別のフィールドの値がXの時だけ必須入力とかはblankかmethodで対応できる?
methodはなんでも屋のつもりだけど、確かに連動必須項目はテンプレ化してもいいかもね。
ただ、シンプルなテンプレ化の方法は少し考えねば…
>入力値の評価と修正が一緒にあるのは気持ち悪いかも
なるほど。ちょっと考えてみる。ちなみに「ascii」も全角→半角変換のつもりw
>>unique
>それはどっかDBとか見に行かなきゃいけないわけで汎用的にならないんじゃ?
まーねー。確かに規約で縛りすぎるのも気持ち悪い。しかし、どう代替しようか。
>>date
>年月日が別のフィールドに分かれてたら3つフィールド名指定できる?
柔軟な日時クラスがあるので、$varnameはymdのarrayでもsqlでもatomでもなんでもおk
>>blank
>別のフィールドの値がXの時だけ必須入力とかはblankかmethodで対応できる?
methodはなんでも屋のつもりだけど、確かに連動必須項目はテンプレ化してもいいかもね。
ただ、シンプルなテンプレ化の方法は少し考えねば…
CakePHP式のバリデーションは便利だよ。
配列&正規表現を工夫すればフレームワークじゃなくて
単なるクラス(か関数)でも用意できる。
配列&正規表現を工夫すればフレームワークじゃなくて
単なるクラス(か関数)でも用意できる。
>>322
>unique
わざわざ用意するまでもなく単にmethodでやればいいんじゃないかな?
削除フラグが立ってない中でユニーク…とかを考えると大掛かりになるし
>$varnameはymdのarrayでもsqlでもatomでもなんでもおk
$_POSTを丸ごと渡すんじゃなくて、
前処理として $ymd = array($_POST['hoge_y'], $_POST['hoge_m'], $_POST['hoge_d']); 的なコードが別途必要ということかな
>ただ、シンプルなテンプレ化の方法は少し考えねば…
必須(blank)に関するチェックに条件が付く場合が殆どで、
他フィールドの値に対して定数との==、!=比較ができれば当分困らないと思う。
'blank' => array(... /*必須にする条件→*/array('eq', 'OtherField', '1')) みたいな
>>323
このあたり既製品じゃ対応しづらい要望が顧客から入りやすい
>unique
わざわざ用意するまでもなく単にmethodでやればいいんじゃないかな?
削除フラグが立ってない中でユニーク…とかを考えると大掛かりになるし
>$varnameはymdのarrayでもsqlでもatomでもなんでもおk
$_POSTを丸ごと渡すんじゃなくて、
前処理として $ymd = array($_POST['hoge_y'], $_POST['hoge_m'], $_POST['hoge_d']); 的なコードが別途必要ということかな
>ただ、シンプルなテンプレ化の方法は少し考えねば…
必須(blank)に関するチェックに条件が付く場合が殆どで、
他フィールドの値に対して定数との==、!=比較ができれば当分困らないと思う。
'blank' => array(... /*必須にする条件→*/array('eq', 'OtherField', '1')) みたいな
>>323
このあたり既製品じゃ対応しづらい要望が顧客から入りやすい
> >unique
> わざわざ用意するまでもなく単にmethodでやればいいんじゃないかな?
そんな気がしてきた。すげーしてきた(笑)。
> $ymd = array($_POST['hoge_y'], $_POST['hoge_m'], $_POST['hoge_d']); 的なコードが別途必要ということかな
いや、フォームの段階で <input name="hoge[year]"... な感じ。
uniqueとかblankとか、少し条件が複雑なものは汎用的な中間methodでも作って…とかやりだすと地獄を見るかな(笑)
> わざわざ用意するまでもなく単にmethodでやればいいんじゃないかな?
そんな気がしてきた。すげーしてきた(笑)。
> $ymd = array($_POST['hoge_y'], $_POST['hoge_m'], $_POST['hoge_d']); 的なコードが別途必要ということかな
いや、フォームの段階で <input name="hoge[year]"... な感じ。
uniqueとかblankとか、少し条件が複雑なものは汎用的な中間methodでも作って…とかやりだすと地獄を見るかな(笑)
バリデート自体は大して実装コストかからないけど、
汎用的かつ、書きやすい構文を考えるのは結構面倒だよね。
汎用性を追求し過ぎると、大抵は既存FWのバリデーターに近い形に落ち着いてしまう。
汎用的かつ、書きやすい構文を考えるのは結構面倒だよね。
汎用性を追求し過ぎると、大抵は既存FWのバリデーターに近い形に落ち着いてしまう。
ECCUBEのコード読んでたときに見つけたんですけど、
// {{{ requires
の {{{ って何ですか?
// {{{ requires
の {{{ って何ですか?
file_put_contents('text.txt', $tweet);
>>336
ドキュメントに載ってないの?
ドキュメントに載ってないの?
>>319
俺もオレオレバリデータ作ったことがある。
ワンタイムトークン的なものつくるとかとか、確認画面用に、値をセッションに格納して読みだして~とかの機能とか
設定したバリデートルールを使って、Javascriptのコードも生成させて、クライアントサイドでも
バリデート出来るようにしたりね。
最近は、jQuery使って、CakePHPのヘルパとかでバリデーションルールをJSONにした物から
クライアントサイドでのバリデーションも連動するようなものを、作りかけた。
まぁ、書き慣れない言語はソースが迷子になって困る。
俺もオレオレバリデータ作ったことがある。
ワンタイムトークン的なものつくるとかとか、確認画面用に、値をセッションに格納して読みだして~とかの機能とか
設定したバリデートルールを使って、Javascriptのコードも生成させて、クライアントサイドでも
バリデート出来るようにしたりね。
最近は、jQuery使って、CakePHPのヘルパとかでバリデーションルールをJSONにした物から
クライアントサイドでのバリデーションも連動するようなものを、作りかけた。
まぁ、書き慣れない言語はソースが迷子になって困る。
>>342
ZFのバリデータ使えばいいと思う
ZFのバリデータ使えばいいと思う
>>345
お前みたいな低レベルに聞いてない。
お前みたいな低レベルに聞いてない。
>>343
OK
OK
>>346
なら、自分で解決しろよwwww
なら、自分で解決しろよwwww
類似してるかもしれないスレッド
- PHP を流行らせるには (224) - [34%] - 2021/3/15 0:45
- 【PHP】気軽にPHP質問スレ (1001) - [33%] - 2013/2/7 9:31
- PHP5 デザインパターン (61) - [32%] - 2019/5/9 7:46
- PHPとJAVAさぶれっと (322) - [30%] - 2018/6/27 23:15
トップメニューへ / →のくす牧場書庫について