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

1 ：02/01/10 〜 最終レス ：11/04/13

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

2 ：

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

3 ：

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

4 ：

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

5 ：

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

6 ：

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

7 ：

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

8 ：

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

9 ：

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

10 ：

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

11 ：

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

12 ：

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

13 ：

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

14 ：

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

15 ：

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

16 ：

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

17 ：

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

18 ：

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

19 ：

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

20 ：

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

21 ：

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

22 ：

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

23 ：

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

24 ：

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

25 ：

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

26 ：

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

27 ：

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

28 ：

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

29 ：

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

30 ：

保守契約は、ちゃんとしておいた方がいいと思うよ。
実際に使われると、なんやかやトラブルが発生するから。
ヘタすると、いつまでも延々、タダでトラブル対応し続ける
ことになる。
どんなプログラマーでも、入門書みたいのからはじめて、
トラブルを経験しては、ノウハウを身につけて
腕を上げていくんだとは思うけど。
損害賠償とか個人に請求されることだけは、避けたい。

31 ：

あと、>23
>一般的にひとつのスクリプトを作り始める時
> 「設計図」は書いた方が良いんでしょうか？
ぜったい書くべき。面倒がらずに。
しょーもないスクリプトでも。
CGIなら、カンタンでいいから画面遷移図は書く。
フローチャート書けるなら、書くに越したことはない。
あとプログラム内で使う変数の一覧表は、作らないと後で困る。
とくに初心のうちに、それもスクリプト言語で作り始めると、
こんがらがってわけのわからないことになりやすい。
つか、まず間違いなく、わけのわからないことになる。
どうしても、「こうするには、こう書けばいけるかな？」
と、試し試し作っていくことになると。
設計が変更につぐ変更になって、イヤになるかも知れないが。
でも、書いたほうがいい。
設計メモも無しに、いきなりガリガリ書いて「動きました」って
プログラムだと、ちょっと直すにもエライ苦労することになる。

32 ：

あと、ついでに。
>> flock 使わない件
>それはどういうことでしょ？ロックしないってことですか？
>それとも他の方法が？
ショッピングカートは関わったことないんで分からないけど。
Webがらみだと途中でプロセスが落ちちゃったときに、
ファイルがロックされたままで動作が止まっちゃうことも考えられるね。
プログラムの書きかた次第とは思うけど。
>＞テキストでデータ吐き出さない方が〜
>？？？？？？？
>今の私の知識の中ではフォームから受け取ったデータに関しては
>「テキスト」で処理するしか思い浮かばないんですが・・・・
プログラム内では、テキストとして処理するけど。
データを、テキストファイルとして出力はするな、ということかな。
とりあえず、データベース使った方がいいよ。
そんな難しいもんではないので。

33 ：

連続ゴメン。
>とりあえず、データベース使った方がいいよ。
って書いちゃったけど、既存のCGI使うんでしたね。
じゃあ、ファイルで処理するのもしかたがないか・・。

34 ：

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

35 ：

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

36 ：

レス感謝です＞皆様
＞３０
なるほどですね。設計書、てかアイディアプロセッサー使って
流れ図と必要項目のリストアップはやって見ます。
＞３４　商品ページを生成するアプリをVBかHTAで作るな。
そうか・・・Accessでも使って簡単なDB作りそのデータを
フォームオブジェクト含んだHTMLに吐き出させれば良いんですかね？
相手の要望で「出来るだけ簡単に」って事だったんでWEBで出来るように
と思ったんだけど、HTMLだけ生成しちゃえば後はFTPだけですからね・・・
う〜ん・・・どっちが簡単なんでしょ？

37 ：

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

38 ：

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

39 ：

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

40 ：

○ 教えてクン養成マニュアル
明日の「教えてクン」を目指す、若き戦士達に以下の文章を捧げる。
日々精進し、パソコンヲタクどもの親切を蹂躙してやれ。
１．努力を放棄すること
　　いやしくも「教えてクン」たるもの、努力をしてはならない。
　過去ログを読んだり、検索してはいけない。
　「英語は苦手なので、分かりません。」は、高く評価できる。
　辞書片手にマニュアルやReadMeを読むなど、決してしてはならない。
　他力本願と言われようと、自分で調べたり試行錯誤したりせず、
　他人の努力の結果を搾取するのが、正しい「教えてクン」である。
　また、「もう何が悪いのかサッパリ分かりません。」と言って
　ふてくされるのも有効である。「サッパリ」という単語が
　「やる気の無さ」を効果的に表現している。
　「原因を特定するには、何をすべきでしょうか？」と訊いてしまうと
　自己の積極性が現れてしまうので、「教えてクン」失格である。

41 ：

２．情報を開示しないこと
　　使用ＯＳや、機器構成などの必須の情報を知らせてはならない。
　マザーボード名やＢＩＯＳのバージョンも同様だ。
　具体的なアプリ名やバージョンも隠蔽すべきだ。
　「ＤＶＤ再生ソフト」のように曖昧に表記しておけばよい。
　反対に「前から欲しいと思っていた○○」とか「安売りされていた
　○○」　等の「どうでもいい情報」は、どんどん書いてやれ。
　　トラブルの場合は、状況を正確に記述してはならない。
　「なんだかうまく動きません。」とか「エラーが出ます。」等と
　具体的なことは何も書かないことが重要である。
　また、自分の試してみた事も具体的に書いてはいけない。
　考えられる組合せのマトリックスを作成し、状況を整理するなど
　もってのほかである。最悪の場合、それだけで問題が解決してしまう
　こともあるのだ。
　「いろいろやってみたけど、動きません。」が理想的だ。

42 ：

３．答える人間のことを考えないこと
「教えてクン」は、孤高の戦士である。相手のことを考えるようでは
　教えてクン失格というものだ。
　以下のような行動が、望ましい。
　　初心者であることを高らかに宣言し、初心者向けの丁寧で
　分かりやすい説明を強要する。専門用語の使用を禁じておくと
　さらに効果的である。簡潔な説明を禁じられたヲタクどもは、
　同じ内容を説明するのに、何倍もの労力を強いられる。
　自分は努力せず、相手には多大な努力をさせることこそが
　「教えてクン」の真骨頂である。
　　マルチポストも有効である。そのＢＢＳを信用していないことを
　明確に示せる。「どうせ、お前らじゃ分からんだろう。」という
　意志表示として高く評価できる。もちろんマルチポストの非礼を
　あらかじめ詫びてはならない。それでは、単なる「急いでいる人」
　になってしまう。それは、教えてクンではない。
　　質問のタイトルは、「教えてください。」で良い。
　タイトルを読んだだけでは「何に関する質問」か全く分からない。
　そういう努力は、答える人間にさせれば良いのだ。
　とにかく、答える人間が答えやすいように気を使って質問しては
　ならない。傲慢で不遜な態度が必須である。
　「聞きたいことがあります。」など、プロの仕事であろう。
最後に、言うまでも無いことだとは思うが、答えてくれた人達に
お礼の言葉を返すなど言語道断である。
せっかく「教えてクン」を貫いてきたのに、最後にお礼を言っている
ようでは、臥竜点睛を欠いていると言わざるを得ない。
質問だけしておいて、後はシカトが基本である。
上級テクニックとして、「そんなことはもう試しました。」とか、
「そこまで初心者じゃありません。」などと言って、回答者の
神経を逆なでしておけば完璧である。
以上のことを踏まえて質問すれば、君も立派な「教えてクン」である。
ビバ！教えてクン！　教えてクンに栄光あれ！！

43 ：

>>39
データの管理をＤＢ使うってことさ。
君の理解した掲示板に例えると題名や投稿者や本文をテキストファイル
ではなくてＤＢのレコードにしまうということ。
プレーンテキストよりはいろいろセキュリティ設定ができるし使用する
ＤＢによっては面倒なロック作業から解放される。
ただし文面から察するにどこぞの共用レンタルサーバーでは使用できな
い場合があるのでご注意

44 ：

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

45 ：

Unix + Perl なら、データベースサーバは MySQL か PostgreSQL で
いいんじゃない？
ロック処理とか、トランザクション処理とか、面倒なことはぜんぶ
サーバがやってくれるよ。
もしサーバ使えない環境なら、PerlのDBモジュール使うしかないかな。
こっちだと、基本的に一枚のファイルでデータを保持することになる。
で、検索にはハッシュを使う。
だから、複雑なデータ処理をする場合や、データ数が数万件とかの規模に
なると、パフォーマンスが低下して、苦しいかもしれない。

46 ：

PHPで作ればいいじゃん

47 ：

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

48 ：

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

49 ：

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

50 ：

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

51 ：

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

52 ：

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

53 ：

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

54 ：

>>52
それで済むならそうすれば？
>>53
>>1読んだ？

55 ：

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

56 ：

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

57 ：

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

58 ：

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

59 ：

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

60 ：

サッ○ー｢もしもし>>1？マミーだけど。あんたなんでこんな駄スレ立てたの？｣
　　　>>1｢うん…｣
サッ○ー｢うんじゃないわよ。それからレスはあったの？｣
　　　>>1｢うん、いろいろあったよ。DBとか、わけがわからなかったよ。｣
サッ○ー｢何て言ったの？｣
　　　>>1｢しらべるの面倒だから、一応あやまってから放置した。｣
サッ○ー｢なんで？こちらは糞スレは立ててない事になってるんだから！｣
　　　>>1｢でも立てちゃったから。２ちゃんねらー相手にごまかせないよ｣
サッ○ー｢だから立ててないって事になってるんだから。裏で色々手を打ってるから大丈夫よ｣
　　　>>1｢でも調べるのめんどくさいもん。やってられないよ。｣
サッ○ー｢それじゃあんた、調べてみますって言っておけばいいのよ｣
　　　>>1｢うん…｣
サッ○ー｢あんたこの文誰かに見られてる？｣
　　　>>1｢見られてないよ｣
サッ○ー｢これはファミリーの問題なんだから。あんたが駄スレ立てたのがばれるとこっちも騙られるのよ｣

61 ：

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

62 ：

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

63 ：

>>50
なんで？
SuExecで、パーミッションしっかりさせておけば外側サーバで大丈夫じゃないの？
ていうか、それ以上のセキュリティを、どうやって確保しろっていうの？
そういうことをアドバイスするんならともかく、一言だけ
＞つか、共有鯖で共有DBMSなんぞ使うな。
＞共有鯖や外側鯖に顧客のプライベートデータを置くことに何の疑問ももたない
＞君らに恐ろしささえ感じる。
こういいっぱなしってのもどうかと思うよ。
真剣に取り組んでる人間だっているんだし。
＞１はどうかしらんけど。

64 ：

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

65 ：

難しくてわけわからない事も多々ありますが、とにかくいろいろレス感謝です。
>>58　各界有名人からの御言葉光栄の至りです
>>60　ただのｺﾋﾟﾍﾟかと思ったらちゃんとｽﾚをトレースしててちょとｳﾂﾆﾅﾀﾖ
>>61
商品の蓄積っていうか・・・
えっと最終的にイメージにあるのは、来訪者（客）が各売場（ページ）で
任意に商品をカートに入れていって、最終的に注文ボタンを押すと
その内容が管理者（店主）と客注文明細のメールが行く、というものです。
で、各商品はそれぞれ色とかサイズとかのオプションをリストボックスから
選べるようにしたりしたい。あと商品写真も載せておきたいですね。
もっと簡単な方法として、商品リストに”購入”のチェックボックス
付けといて、チェックの有る無しで注文品を抽出するというのも考えたんですが、
やっぱり「カゴに入れる」っていうイメージのものを作りたいもんで・・・・
アイディアというか考え方のTIPSみたいのをもらえたら良いかな？
と思って立てたｽﾚなんですが、教えて君になっちゃってるみたいで
申し訳ないです。

66 ：

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

67 ：

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

68 ：

>>63
> SuExecで、パーミッションしっかりさせておけば外側サーバで大丈夫じゃないの？
プライベートデータはS/MIMEで送っちまえばsuExecより安全。
どんなに優れた攻撃者でも無い物は盗めない。
まず、置かない事を考えたほうが良いよね。
> こういいっぱなしってのもどうかと思うよ。
> 真剣に取り組んでる人間だっているんだし。
商用DBは知らないけど、PostgreSQLやmySQLは攻撃対象になってないと
いうだけで、結構穴あいてるでしょ。
例えば、FreeBSD portのPostgrSQLなど、デフォルトインストールはlocalhostが
trustになってる(なってた)けど、セキュリティに気を配ってるとは考えられない。
*

69 ：

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

70 ：

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

71 ：

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,商品名・・・など

72 ：

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

73 ：

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

74 ：

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

75 ：

区切りはタブがよい

76 ：

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

77 ：

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

78 ：

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

79 ：

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

80 ：

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

81 ：

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

82 ：

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

83 ：

> 今回は教えて君です、すいません。
毎回そうだろ。

84 ：

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

85 ：

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

86 ：

　　　　　　　　　　∧　　　　　　 ／ヽ
　　　　　　　　　/　　ヽ　　　　/　　　ヽ
　　　　　　　　 l　　　　レ──l　　　　ヽ
　　　　　　　　j　　　　　ヽ　　　　　　　　ヽ
　　　　　　 ／　　　　　　　　　　、　　＿　ヽ
　　　　　 /　　　　　　　__ ﾉ　　　ヽ￣・ﾉﾉ　l　　>>1　んなことシラネーヨ
　　　　　/　　　　λ￣ ・ノ　　　　 ｀⌒　　　l
　　　　 l　　　　　　 ｀⌒　　　　　 、　　　　　l
　　　　 l　　　　　　　　　λ＿＿ノ　　　　　 l
　　　　　ヽ　　　　　　　　ヽ| | | /　　　　　 /
　　　　　　ヽ　　　　　　　　　￣ﾌ　　　　ノ
　　　　　　　　ヽ ＿　　　　　　　 ＿─ ´
　　　　　　　　　　　￣＼　<´￣ 　　　　　　　/|
　　　　　　　　　　　　　　＼.＼＿＿＿＿__／/
　　　　　　　　　　　　　　　 ＼　　　　　　　／
　　　　　　　　　　　　　　　　　∪∪￣∪∪

87 ：

まー気持ちは分かるよ。
関数の有る無しとかってより、ノウハウの部分を聞きたいんじゃないの。
>>80
とりあえず、プログラム中で計算に使うなら、その変数は
数値データにしておいた方がいいんじゃないの。
で、画面に表示する時だけ,を挿入する。
「計算に用いるデータだけど,を含んでいます」とか
イレギュラーなことは、俺ならとりあえず避けるな。

88 ：

ふと思うがなんでこのスレって人気あるんだろう？
っていいながら見てるオレも不思議なんだがな（わら

89 ：

>>85
以後気をつけます。
>>87
ありがとうございます。やはり、方法としてはそうなりますか。
カンマ挿入用のサブルーチン作って、とりあえずカンマが
必要な時はそれを使うことにして進めていこうと思ってます。
ただ,そういう場面が多いと一々subを呼び出す事になるんですが、
そういうのって良いんでしょうか？

90 ：

>>89
そういう感じでよいんでない？その都度微妙に処理が異なるならともか
くとして同じならサブルーチンでしょ。
ちなみにその使用だと入力されたデータを数値として揃えるサブルーチン
も必要になるよね。
がんばってね

91 ：

>>88
いかにショッピングカートって仕組みが必要とされているかって事だと思うよ。

92 ：

>>89
しょうがないな〜、JAPUたんが最近いないので、
変わりに教えてあげるYO！
print "合計金額",comma($total);
sub comma{
($_) = @_;
1 while s/(.*[0-9\?])([0-9\?]{3})/$1,$2/;
$_;
}
こんな感じかな。

93 ：

>>92
ありがとうございました。m(__)m
実は、一応なんとか書きあがってたんですが・・・・(汗

94 ：

>>89
>ただ,そういう場面が多いと一々subを呼び出す事になるんですが、
>そういうのって良いんでしょうか？
ぜんぜん問題ないよ。それで普通。

95 ：

もう諦めてPHPでつくりなさい

96 ：

>>1
俺達これだけ協力したんだから、
できあがったスクリプトをちゃんとUPしてね。
それくらい分かってると思うけど。

97 ：

>>96
完成がいつになるかわからないけどガムバってみます。
＃進捗状況
フォームから受け取ったデータをタブ区切りでTMPファイルに
書き込み、そのデータを配列に格納して、HTMLにテーブルで表示する。
ようやくこれだけ出来ました。タブ区切りのひとつひとつのデータを
\nを区切りとして配列にして、それをさらに\tを区切りとして配列にしてから
テーブルに埋め込んで表示させました。カートの中身を表示する部分の実験です。
＃次の予定
テーブルの列の最後に「削除」ボタンを表示させ、それを押したら
その列を削除（カートから消す）という方法を見つけたいと思います。
配列の最後に何かデータをくっつけさせてそれが有るか無いかで判断させて
削除しようと思ってるんですが・・・・・

98 ：

ﾀﾞﾐﾀﾞ・・・・・
とりあえず寝よう・・・
なんか、根本的に削除の方法論が間違ってる気がする・・・・・

99 ：

例えばだね。
注文（注文番号　商品番号　注文個数　顧客番号）
商品（商品番号　商品名　単価　写真ファイル名）
顧客（顧客番号　氏名　連絡先）
などというテーブル構成にして、画面上では注文の部分のみを扱う
それぞれの番号には同じ数字を重ねない。
で、削除の場合。削除確認のラジオボタン（かなにか）をチェックする
と削除する注文番号が飛んでいってその注文番号と一致するレコード
なりファイルなり配列なりクッキーを消せば(･∀･)ｲｲ!!だけじゃない？

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

僕に系のシステムを売ってください (919)
Blog/Wiki関連技術総合 (350)
【PHP】フレームワークPharonスレ (292)
WebLogic に詳しい人いません。 (615)
Ajax vs Javaアプレット vs FLASH (337)
プログラム言語遍歴 (294)
--log9.info------------------
過大評価】 MCDシルフィード被害者集合 【垂れ流し (655)
アクスレイ AXELAY (596)
レイストームHDは9割方こけない (843)
イルベロ イルマティック・エンベロープ 4鍵目 (565)
ソルジャーシリーズ総合スレ　3連射目 (582)
exception 豆腐1丁 (786)
【Wii】コールオブデューティ3【体感】 (236)
ファンタジーゾーン総合スレ２ (595)
シューティングで黒歴史なもの (831)
【本家本元】首領蜂・怒首領蜂 Part.13【非大往生】 (211)
面白いSTG (830)
【XBOX360】オトメディウス ゴージャス！ (573)
【よくしん】翼神ギガジェネ6京点目【終了】 (877)
エアフォースデルタ ブルーウイングナイツ (474)
エスコン厨と東方厨はシューターの中の最底辺 (867)
式神の城II 攻略スレ七式 (919)
--log55.com------------------
嫌いだけど人に言えない200
【園芸】ガーデニング大好き奥様＠75株目【庭ｲｼﾞﾘ】
【画像】3248
■■家を建てた奥様より家を建てる奥様へ 166軒目■■
子育てを終えた奥様 18
忘れられない怖い事件215件目
おっさんずラブが楽しみで仕方ない奥様 Part.3
【虐待母】藤原家の毎日家ごはん233【ヒモ旦那】