☆ショッピングカートのCGIを作りたい！Perlで☆

知り合いにWEBショップ作ってくれと頼まれたのは良いけど、
フリーのショッピングカートCGIは設置は簡単でも、商品の登録
とかが手作業だったりで使い勝手が悪いです。
で、短絡的に「自分で作ってみようか」と思っているのですが・・・・
Perlも、いやプログラミングさえ未経験。「必ずわかるCGI」と
その他の入門書で何とか「掲示板」の仕組みがようやく理解できました。
やっぱ、無謀ですかねぇ・・・・・・

2ゲット。
やってみれば？
しかしそれをそのまま商売につかうとなると
イロイロ危険だと思われ

ﾚｽありがとうございます。で、ちょっとお聞きしたいんですが、
掲示板スクリプトとかって、かなり高機能な奴もそこらじゅうで「フリー」
で転がってますけど、ショッピングカートって、ちょっと使い勝手が良くなると
みんなシェアになってますよね？
これって、やっぱり掲示板なんかに比べて圧倒的に
手間がかかる＝作るのが難しい
のでしょうか？それともスクリプトの性質上「利益を生む」物なんで
「金稼ぐんだから、少しくらい払っとけ」的な考え方で、
作る手間＝技術
は掲示板なんかとそれほど変わらないものなんでしょうか？

やってみれば。
テキスト弄りまわすだけだから丁度良いんじゃないかな
それと出来たらそのWEBショップの名前教えてくれる？
絶対そこ利用しないから　（笑

＞４
えっと・・・・
まぁ、もし出来上がったとして穴だらけになるのはわかっているのですが・・
そういう場合って、設置者（お店）側だけじゃなく、利用者（お客さん）側
にもリスクがあるような穴が出来る可能性があるってことですか？

もしそうだとしたら・・そうでないにしても、ｾﾞｯﾀｲに注意しなくちゃいけないことって
何がありますか？

リスクて、、、、
カードのID漏れたらどうすんのさ　（´＿｀；）
DBを生でネットに晒すのは狂ってるよ

>>3
シェアにしてるのは、金儲けに利用するなら
作者にもチットは金貰う権利があるでがしょってことでしょうね。
難しさに関しては一概には言えないと思います。
BBSにもショッピングカートにもいろいろあるし、
同じ機能でも速さがエラく違う場合もあるので。
しかし、若干カートの方が難しくなりがちかも。
個人情報にきちんと配慮するとなると
ショッピングカートの方が、スクリプトを組む前に
必要な知識は増えるでしょう。
作る前に>>5のような事がわかってないと危険。

ども・・
カードに関してはどっちにしろSSLが使えない鯖の可能性もあるので
基本的には支払の項目で、｛カード、代引き、振込み｝を
選べるようにしておいて、後でメールででも確認するような形になるかと・・・
でもSSLとか使えないと、住所等の情報も危険に晒されるわけですよね・・・
はてさて・・・・・・・

やる前に確認できる事って限られているので
簡単なものを試しに作ってみるしかないでしょうね。
スポーツ、料理、デザイン、プログラミング・・
何にしても、概要を知るのと実践とでは次元が違うでしょ？

ところで、その辺のセキュリティ関係勉強しとくのに必要な
キーワードってなんでしょう？書店で本探すにしても何から
手をつけていいかわから無いので・・・・
今のところSSLって言葉しか頭に浮かばないんですが

LANのPCで試すんでしょうから、とりあえず、鯖のインストール・設定から
テストスクリプトの作成・設置までやってみたらどうですか。
そこでかなりの部分が勉強できると思います。

＞２さん
親切にありがとうございます。
とりあえず、今のところローカルのHDにapacheとPerl入れて
テストの出来る環境は整ってます。
家のネットワークがWin2000S使ってプロ串経由でCATVにつなげているのですが
Win2000SにApachとか入れちゃうと外部からのアクセスとかが恐いので
端末になってるWin2kProの機械の中でテスト環境作りました。
一応、本に載ってる「掲示板もどき」は打ち込んでみて、ページを行き来
しながら、処理の内容を理解できるようにはなってきました。
次はファイルのロックとか、一度登録したものの削除とかを試そうと
思います（flockに関してはwin環境じゃ動かないらしいですが・・・・・）

>>12
ショッピングカート作るんだったら、flockとか使わないことをおすすめするよ。

ちょっと話はずれるかもしれませんが、僕も最近バイトができたらと
いう少し不純な動機でperl始めました。
まだブラインドタッチもままならない状況で無謀者さんよりもさらに無謀
な挑戦をしています。
おたがい結構大変な挑戦をやってますけど頑張りましょう！応援してますよ。

それはどういうことでしょ？ロックしないってことですか？
それとも他の方法が？

>>15
うん。ていうか、テキストでデータ吐き出さない方がいいって事かな？

＞テキストでデータ吐き出さない方が〜
？？？？？？？
今の私の知識の中ではフォームから受け取ったデータに関しては
「テキスト」で処理するしか思い浮かばないんですが・・・・
他にどのような方法があるのでしょう？txtじゃなければバイナリ？
受け取ったデータを何か加工するのでしょうか？

>>17
カートと商品の大きさにもよるけど、DB連動とったりした方が安全かな？
tieつかってGDBMに納めたりね。
お金が絡むcgiになるから、そのあたり慎重に考えた方がよいと思います。

>>18
カートと商品の大きさっていっても、実寸じゃなくて、データの大きさです(笑)。
読みにくい文章でごめんね。

・・・もうわけわかめ・・・・
DB連動、tie、GDBM・・・全て初耳です。
ちと調べてみます。

しかし、２ｃｈって多少の煽りにめげなければ、情報収集したり、
アドバイス貰うのに良い場所だと思ってこの板でｽﾚ立てたは良いけど
ｽﾚが気になってエディタに集中できないという諸刃の剣(w

>>12
もし公開鯖がUNIX系なら、LANの方もそれにしておいた方が何かと良いです。

もうひとつ、「プログラミング的な物の考え方」にいついて質問させてください。
一般的にひとつのスクリプトを作り始める時「設計図」は書いた方が良いんでしょうか？
はるか昔にベーシック（PC-8001)をかじろうとした頃は「フローチャートを書く」みたいなのが
あったと思うのですが・・・
それともいきなり書き始めて、後で必要になった処理を継ぎ足すなり
割り込ませるというのは可能ですか？可能にしても相当めんどくさく
なるもんなんですかね？

＞２２＝２さん
公開鯖は間違えなくUNIX系なんですが、LAN環境にLinuxなりを導入
しようとすると、Perl云々以前にそれに時間を取られ、スクリプトを
書く段階までたどり着けないような気がするので・・・
ある程度Perlがわかってきて、簡単なスクリプトを”自分で”書けるように
なったらLinuxも導入しようとも考えてるんですが、今の段階ではPerlでCGI
を書くことを優先したいと思ってます。

>>23
その程度のことは入門書にも書いてあるんで
読んだら良いかと思われ。
あとは、経験を通して身に染みてというか
身についていくものと思われ。

>>24
結局、>>22は遠いようで近道になるんですが、
まあ、やりかたは人それぞれでしょうな。
どんなトラブルも後からすれば肥やしになるでしょうから。
商売だとクレームになったりしてアレですけど。
では私はこれで。

こういう奴が作ったECサイトでは買い物したくないな。

セキュリティ（SSL）はVeriSignへの登録が手っ取り早い。
http://www.verisign.co.jp/
年間10万円ちょっとかかりますけど。
カートはゼロから作ると大変。フリーなどを改造した方が良いと思われ。
鯖は安価で高性能のものが数千円/月〜。
小規模サイトなら重要データにDBは使わず、フォームメールで注文を飛ばし、
メーラー側でDB(Accessなど)に格納（フリー or 数千円〜）がおすすめ。
中規模〜なら鯖からDB(MySQL・Postgresなどバイナリデータ)への接続が必要。
初心者が短期間に構築するのは無理かと・・・でも応援します。
俺も作りたいって思ってるから。

う〜ん、話がどんどん難しくなってる・・・・
依頼主が非常に小規模なのでVeriSignへの登録は無理かも。
カートはフリーでユーザー側のインターフェースがﾜﾘと
使いやすい奴は見つけたんですけど、商品ページをいちいち手書き
でフォーム使って作らなきゃならない。一度商品登録して”はい終り”
てのなら良いんですが、あまり詳しくない人が商品登録の為に商品ページに
フォームと各オブジェクトを配置、それぞれに属性指定せねばならず、後々面倒なことになりそう。
で、最初に考えたのが、フォームからデータを受け取って、そのフリーのカート
に必要なフォームを出力するCGIを作ろうということでした。
そうすれば、カート部分は完成してるので、商品登録だけ出来るものなら
ﾜﾘと簡単かな？と・・・・
で入門書とか読んでるうちに、「どうせなら」と思い、1から作ってみよう
と思ってるところです。
長文ｽﾏｿ＆応援感謝

保守契約は、ちゃんとしておいた方がいいと思うよ。
実際に使われると、なんやかやトラブルが発生するから。

ヘタすると、いつまでも延々、タダでトラブル対応し続ける
ことになる。

どんなプログラマーでも、入門書みたいのからはじめて、
トラブルを経験しては、ノウハウを身につけて
腕を上げていくんだとは思うけど。
損害賠償とか個人に請求されることだけは、避けたい。

あと、>23
>一般的にひとつのスクリプトを作り始める時
> 「設計図」は書いた方が良いんでしょうか？

ぜったい書くべき。面倒がらずに。
しょーもないスクリプトでも。
CGIなら、カンタンでいいから画面遷移図は書く。
フローチャート書けるなら、書くに越したことはない。
あとプログラム内で使う変数の一覧表は、作らないと後で困る。

とくに初心のうちに、それもスクリプト言語で作り始めると、
こんがらがってわけのわからないことになりやすい。
つか、まず間違いなく、わけのわからないことになる。

どうしても、「こうするには、こう書けばいけるかな？」
と、試し試し作っていくことになると。
設計が変更につぐ変更になって、イヤになるかも知れないが。
でも、書いたほうがいい。

設計メモも無しに、いきなりガリガリ書いて「動きました」って
プログラムだと、ちょっと直すにもエライ苦労することになる。

あと、ついでに。

>> flock 使わない件
>それはどういうことでしょ？ロックしないってことですか？
>それとも他の方法が？

ショッピングカートは関わったことないんで分からないけど。
Webがらみだと途中でプロセスが落ちちゃったときに、
ファイルがロックされたままで動作が止まっちゃうことも考えられるね。
プログラムの書きかた次第とは思うけど。

>＞テキストでデータ吐き出さない方が〜
>？？？？？？？
>今の私の知識の中ではフォームから受け取ったデータに関しては
>「テキスト」で処理するしか思い浮かばないんですが・・・・

プログラム内では、テキストとして処理するけど。
データを、テキストファイルとして出力はするな、ということかな。

とりあえず、データベース使った方がいいよ。
そんな難しいもんではないので。

連続ゴメン。

>とりあえず、データベース使った方がいいよ。

って書いちゃったけど、既存のCGI使うんでしたね。
じゃあ、ファイルで処理するのもしかたがないか・・。

漏れなら、商品ページを生成するアプリをVBかHTAで作るな。
ま、初心者が穴のあるCGI乱造してくれるのは大歓迎だ。

>>34
CGIでもいいんだよ。
ローカルのPCで実行して、アップするやり方にすりゃ安全。
開発も早いだろうし。

レス感謝です＞皆様
＞３０
なるほどですね。設計書、てかアイディアプロセッサー使って
流れ図と必要項目のリストアップはやって見ます。

＞３４　商品ページを生成するアプリをVBかHTAで作るな。
そうか・・・Accessでも使って簡単なDB作りそのデータを
フォームオブジェクト含んだHTMLに吐き出させれば良いんですかね？
相手の要望で「出来るだけ簡単に」って事だったんでWEBで出来るように
と思ったんだけど、HTMLだけ生成しちゃえば後はFTPだけですからね・・・
う〜ん・・・どっちが簡単なんでしょ？

>>35
そーか? CGIというインターフェースを介する分だけ余計な手間がかかると思うが…
perlだってActive Scriptで書けるんだろ? だったらHTAだ。
どっちにしろ、ローカルで設定ファイル生成するアプリ作るが吉。
使いやすけりゃ売れるぞ。

>>36
CGIは状態を持てない、それゆえ自分で状態を管理しなけりゃならないから面倒。

ところでデータ-ベースを使うってのはどういうことなんでしょうか？
サーバー側のそういう機能を利用すると言うことでしょうか。
IISとかだとSQLとかODBCとかASPって「言葉」がなんとなく思い浮かぶんですが
UNIXベース＋Perlでも同じような事なんでしょうか？

>>39
データの管理をＤＢ使うってことさ。
君の理解した掲示板に例えると題名や投稿者や本文をテキストファイル
ではなくてＤＢのレコードにしまうということ。

プレーンテキストよりはいろいろセキュリティ設定ができるし使用する
ＤＢによっては面倒なロック作業から解放される。

ただし文面から察するにどこぞの共用レンタルサーバーでは使用できな
い場合があるのでご注意

>>43
他にはデータの検索をしたい時にいちいち検索するための複雑なスクリプトを
自分で作らなくてもちょこっと SQL 書くだけで欲しいデータを素早く取り出せて
(ﾟдﾟ)ｳﾏｰ ってのはあるね。多少データベースの設計と SQL を勉強する必要は
あるけども。Perl だと DBI で DBMS にアクセスするのが一般的かな。
こんな本も出てるみたいだよ。

http://www.oreilly.co.jp/BOOK/perldbi/

Unix + Perl なら、データベースサーバは MySQL か PostgreSQL で
いいんじゃない？
ロック処理とか、トランザクション処理とか、面倒なことはぜんぶ
サーバがやってくれるよ。

もしサーバ使えない環境なら、PerlのDBモジュール使うしかないかな。
こっちだと、基本的に一枚のファイルでデータを保持することになる。
で、検索にはハッシュを使う。
だから、複雑なデータ処理をする場合や、データ数が数万件とかの規模に
なると、パフォーマンスが低下して、苦しいかもしれない。

PHPで作ればいいじゃん

取りあえず動作するCGIは比較的簡単にできるけど、
堅牢なそれを作るのは大変だよな。

>>45
>こっちだと、基本的に一枚のファイルでデータを保持することになる。
どういう意味でいっているのかわからないけど、tie使うって意味合いでいってるんだったら
そんなことないっす。

>>48
ほんとだ。
余裕で複数のファイルからデータ取ってきてマージして
使ったりできた。しかもBツリー使う引数もあった。
ゴメソ。

つか、共有鯖で共有DBMSなんぞ使うな。
共有鯖や外側鯖に顧客のプライベートデータを置くことに何の疑問ももたない
君らに恐ろしささえ感じる。

う〜んだんだん・てかどんどん難しい話になってきちゃいましたね。
自分としては、カートCGIなんかもシェアとはいえﾜﾘと普通に配布
されているし、ためしに設置してみてもそんな特殊な事やってそうも無いので
掲示板なんかに比べてちょっと複雑な位かな・・・程度に思ってたんですが。
いや、確かにある程度の規模のWEBショップ構築するならセキュリティとか
相当大変なんでしょうけど、個人商店とかで騙されて楽天とかに出店して
全然元が取れてないような規模の商売のところってあると思うんですよ。
ちょっと分けます

で、一番単純なWEB通販の方法として,商品リストをHPに載せておいて
欲しいものをメールで送ってもらう。
てのがあると思うのですが、それだとあまりにも使い勝手悪い。
形だけでもショッピングカートがついてると、フォームで（ブラウザで）全てが
済むから、お客さんも買いやすいでしょ？だから極端な話、お客さんの個人の情報
はフォームに入れなくても良いかな？って感じです。注文商品とメールアドレス
だけを取得できれば、住所、電話等は後でメールでやり取り・・・ってのも
ありだと思うんですがいかがでしょ？

>>52
それはただのフォームメールで十分じゃねーかよ
別にカート使わなくてもＯＫでしょ。
あと君の言った商品管理にもテキストよりＤＢの方が使いやすいと
みんなが言ってくれてるの。
ご理解いただけてる？
ってか君はどれくらいのスキルなのか教えてくれないか？
ＣＧＩは初めてだということはわかるが他の分野のプログラマなのか？

>>52
それで済むならそうすれば？

>>53
>>1読んだ？

いろいろご提案いただいてる皆さんにちょっと、言い方が失礼だったかもしれませんね。
すいませんでした。
>>53
＞それはただのフォームメールで十分じゃねーかよ
フォームメールだと基本的に内容は自分で書かなきゃいけないですよね？
私としてはそれぞれの「購入」ボタンを押していって、購入商品を積み重ねていって
その結果をメールで送信するって言う形にしたいんです。もちろんセキュリティ
が確保できれば住所等個人情報もフォームで送りたいんですが・・・・
基本的には客側にあんまり考える時間を与えずフォームのクリックだけで
注文できる、って方式のほうが買ってもらいやすいと思うので・・・
まぁ、「そんなこと以前に客を集められるHP作れ！！」って話もあるんですが
それはまた別の話と言うことで（ｗ

☑購入
チェックボックスつけりゃ、フォームtoメールでいいだろ。
それからSSL使わないんだろ？
どっちなんだよ、ハッキリしろヴォケ！

商品のページが１ページだけなら、おっしゃる通りの方法でも大丈夫
だと思うんですが、複数ページにまたがっていてもその方法で大丈夫でしょうか？
一応商品カテゴリごとにページを分けたいといわれているので・・・・

で、SSLはとりあえず使わない方向でお願いします。

１がこのスレを立てたことについて各界の反応

総理大臣／小泉純一郎さん 「何で今さら、こんな質問が出てくるのか分からない」
自由党党首／小沢一郎さん 「（事務所を通じて）コメントする価値を見いだせない。」
東京都知事／石原慎太郎さん 「くだらないねえ。何が楽しみでこんなスレ立てるのかな。連中は。」
日銀総裁／速水優さん「頭の中までデフレが浸透していると、再認識せざるを得ない。」
ソニー会長／出井伸行さん 「ブロードバンドが普及すれば、こういう削除も速くなると思う。」
白鴎大学教授／福岡政行さん 「やっぱり自公保連立政権の発足からこういうスレが増えたと思います。」
タレント／デーモン小暮さん 「わが輩が地球を征服した暁には１から処刑するぞ。グハハハハ。」
新しい教科書を作る会／西尾乾二さん 「このスレほど戦後民主主義教育の欠陥を表しているものはない。」
元グリーンベレー／柘植久慶さん「海外にはこの程度の変質者はコンビニにもいる。日本が平和すぎた。」
女優／広末涼子さん「こういう人がいる日本って、やっぱりすごすぎると思う。」
プロデューサー／テリー伊藤さん「１は本当にバナナの皮を踏んで滑ってこけそうな人だよね。」

>>58
そんなこたないよ。
何でそんなに怒ってんのさ？

>>55
商品の蓄積？ってか商品は何点あるのさ？ってか予定でもいいから教えて
お客さん自体が一回の注文に数点注文するような性質の商品なのか？
蓄積自体は君が思ってるほど難しくはないのだよ。
問題は君自身がどういうものを作りたいかがわかっていないことに起因
していると思われ
とりあえずフォームTOメールのスクリプトを自分で書いてみてそこの
機能を追加していったらどうかね？何ができるかわからない状態では
お答えする方が疲れる

ショッピングカート系の仕様って、概要のシェイクダウン大変だよね。
設計ちゃんとしてないと、後が大変だし。
たいてい「●●が不満なので改良してほしい」
みたいなののソース見ると
「一から作り直した方が早いです」
みたいな状況になってることも多いし。
他の人にとっても、そういうものなのかな？

>>50
なんで？
SuExecで、パーミッションしっかりさせておけば外側サーバで大丈夫じゃないの？
ていうか、それ以上のセキュリティを、どうやって確保しろっていうの？
そういうことをアドバイスするんならともかく、一言だけ

＞つか、共有鯖で共有DBMSなんぞ使うな。
＞共有鯖や外側鯖に顧客のプライベートデータを置くことに何の疑問ももたない
＞君らに恐ろしささえ感じる。

こういいっぱなしってのもどうかと思うよ。
真剣に取り組んでる人間だっているんだし。
＞１はどうかしらんけど。

注文から先はうちはSSL使ってるよ。
ベリサインじゃないけどね。

難しくてわけわからない事も多々ありますが、とにかくいろいろレス感謝です。
>>58　各界有名人からの御言葉光栄の至りです
>>60　ただのｺﾋﾟﾍﾟかと思ったらちゃんとｽﾚをトレースしててちょとｳﾂﾆﾅﾀﾖ

>>61
商品の蓄積っていうか・・・
えっと最終的にイメージにあるのは、来訪者（客）が各売場（ページ）で
任意に商品をカートに入れていって、最終的に注文ボタンを押すと
その内容が管理者（店主）と客注文明細のメールが行く、というものです。
で、各商品はそれぞれ色とかサイズとかのオプションをリストボックスから
選べるようにしたりしたい。あと商品写真も載せておきたいですね。
もっと簡単な方法として、商品リストに”購入”のチェックボックス
付けといて、チェックの有る無しで注文品を抽出するというのも考えたんですが、
やっぱり「カゴに入れる」っていうイメージのものを作りたいもんで・・・・

アイディアというか考え方のTIPSみたいのをもらえたら良いかな？
と思って立てたｽﾚなんですが、教えて君になっちゃってるみたいで
申し訳ないです。

Tips
http://www.jadma.org/kisei/jyouhou/seibi.html

>>65

この板でPerl修行中の者ですが、この手のものなら
蓄積量が少なければ、フォームの中にHIDDEN属性で情報を
追加していくことで、簡単に作れるような気がしますね。

>>63
> SuExecで、パーミッションしっかりさせておけば外側サーバで大丈夫じゃないの？
プライベートデータはS/MIMEで送っちまえばsuExecより安全。
どんなに優れた攻撃者でも無い物は盗めない。
まず、置かない事を考えたほうが良いよね。

> こういいっぱなしってのもどうかと思うよ。
> 真剣に取り組んでる人間だっているんだし。
商用DBは知らないけど、PostgreSQLやmySQLは攻撃対象になってないと
いうだけで、結構穴あいてるでしょ。
例えば、FreeBSD portのPostgrSQLなど、デフォルトインストールはlocalhostが
trustになってる(なってた)けど、セキュリティに気を配ってるとは考えられない。

>>67
客に入力してもらう以外の必要項目（価格、商品名等）をHIDDEN属性で
指定しておけば良いらしい。ということはなんとなくわかってきました。
作る順番としては、とりあえずフォームを作ってそれを受けるカートのCGIを
作り、その後その仕様にあったフォームを作るためのスクリプトを書いて行く予定です。
いろんな本で調べながらなんですが、今のところわからないのが、
買物途中にテンポラリファイルに格納された「買物商品のデータ」を
客が「ヤッパ要らない」となったときに削除する方法です。
「買い物カゴの中身表示」の画面に削除ボタンをつけとく事になるんでしょうが、
それをどうやって処理するのか・・・・

>>69
カゴに品物入れて、そのまま他のサイトに飛んでったら
テンポラリファイルは残したままにしますか？

opne(IN,"<$file");
@data = <IN>;
close(IN);
@dataの中をmapなどで編集
--例--
map {
@cell = split(/,/, $_);
if (@cell[0] eq $in{'dellitemid'}) { $_ = ''; }
} @data;
opne(OUT,">$file");
print OUT @data;
close(OUT);
------------------
<$fileの中身の設定>
1024,電気ストーブ,・・・etc
商品ID,商品名・・・など

>>71
CSVですか。
商品名とか金額にカンマが入ったときの対策が要りますね。

>>70
そうか、そういう可能性も考えとかなきゃいけないんですね。勉強になります。
理想はある程度時間がたったら買物を終了しててもしてなくても削除ってところでしょうか。

>>71
入門書読みながら、意味理解してみます。ありがとうございました。

>>1って何やってる人？

区切りはタブがよい

>>1
書籍で勉強するのも大事だけど、実際にコードを書いてみないと
ダメだと思いますよ。
ここまで読んだ限りでは、考えるだけで一行も書いてないように
思えます。
今のままでは、「脳内カート」で終わるでしょう。

せめて、配布されてるCGIの改造をしてみるとか。

>>76
いろいろ書いて（てか打ち込んで）みてはいます。
ただいかんせん、”プログラム”という経験が皆無に限りなく
近いので、配列だとかの概念から一つ一つ確認しながらなので
いきなりカートを作れる状態ではありません。
現在は書籍に書いてある、掲示板スクリプトを弄繰り回しながら
その流れを一つ一つ噛み砕いている段階です。
それと平行しながら、自分で考える”カート”の設計図
というか流れ図みたいのを書きながら、ここでいろいろ
参考にさせていただいております。

>>77
あぁ、全くの初心者か…
ここあたりも見て置くように。動かすだけじゃ駄目。
http://choco.2ch.net/news/kako/1010/10103/1010387528.html

>70
普通はテンポラリファイルって消すんだろうけど（方法は知らないけど）、
途中で買い物を止めたって人の統計を取るために、何らかの形で
残した方がよくないですか？
例えば($section=買い物の段階、$cart=カートに入れた商品数)
カゴに1商品だけ入れて止めた ＝ $section=1;$cart=1
カゴに3商品、住所等入力画面で止めた＝ $section=2;$cart=3
カゴに5商品、最終確認画面で止めた＝ $section=3;$cart=5
アクセスがあるのに何故買わないのか？を調べた方がよいと思われ

先にお詫びしときます。今回は教えて君です、すいません。
えっと、カートとかで”金額”を扱うのに、普通”,”を入れますよね
20,000　みたいに、で個数とかを計算させて、
kingaku*$kosu
ってやると20,000*2でやると40って数字が帰ってきます。
こういう処理ってのは、普通20000*2で計算させて、出力時にカンマを挿入
するんでしょうか？それとも数値に自動的にカンマを入れて表示させるような
関数があるんでしょうか？もし前者だとすれば、

$kingakuにカンマが入っていたらそれをはずす
$kingaku*$kosuを実行する
計算結果ににカンマを入れる

とかの処理をカンマ付の数字を出力するたびにやることになるのでしょうか？

>>79
なるほどですね。店主の人にはその機能はいいかもしれません。
ただ、全ての利用者（中途キャンセル者も含む）のログとっておくと
鯖のスペース圧迫しますよね。サイトの規模にも拠ると思いますが。
って、定期的にログ削除すればいいのか・・・・

申し訳ありません。ぐぐるで発見できました。

> 今回は教えて君です、すいません。

毎回そうだろ。

>>80
数値へのカンマの付け方は「Perlメモ」参照してください。
http://www.din.or.jp/~ohzaki/perl.htm#NumberWithComma
関数があるかどうかはリファレンス系のサイトをどうぞ、
そんな処理にいちいち関数あるか知りませんが・・・。

>>82
調べずにここで訊くのが習慣化されてんだね。
教えて君です、すいませんなんて書いてる暇があったら
グーグルで検索しろ。

まー気持ちは分かるよ。
関数の有る無しとかってより、ノウハウの部分を聞きたいんじゃないの。

>>80
とりあえず、プログラム中で計算に使うなら、その変数は
数値データにしておいた方がいいんじゃないの。
で、画面に表示する時だけ,を挿入する。

「計算に用いるデータだけど,を含んでいます」とか
イレギュラーなことは、俺ならとりあえず避けるな。