a-blog cms でフォームが送れない時に確認すべきこと

最近めっきり寒くなりました・・・というか突然寒くなりました。

さて、12月。
Advent Calendarの時期ですね。

今回は「フォーム」について。特にうまく送信できないトラブルにお困りの方へ。

なお、この記事はa-blog cms Advent Calendar 2014 - Adventarへの寄稿です。

例として、メール、名前と連絡内容だけを送信する単純なフォームをつくってみると

こんなやつね

f:id:nisyu:20141204141229p:plain

HTMLソースは最終形としてはこのようになります。

最低限動くところまでですが、まず注意するところは通常よく使う「モジュールID」と違ってフォームIDは

  <input type="hidden" name="id" value="contactForm" />

の形式でHTMLのフォームデータとして渡します。（公式のサンプルを見たら毎回入れてあるのでそのように書きましたが、実際には最後の「送信」のフォームに付いていれば動くはずです。）

・・・未だにたまにFormモジュールにidを書きたくなります。

複数の画面を渡って行くときにstep#reapplyのようなstepを指定するブロックで表示する画面を指定します。

これらも、サンプルではよくあるパターンで書いていますが、実際には好きな名前で指定できます。

ただ、画面遷移にあたって送信ボタン（ type="submit" ）のname指定と、formの送信先（ action ）、フォームのstepの値に注意が必要です。

フォームの送信先（formタグのaction属性）には step=***という指定で、このデータを送信する先を指定しています。a-blog cmsではここにはそのフォームを送信した後に「バリデーションなどでエラーがあった場合」に表示されるstepを指定します。

フォームデータとしてのstep（のように記述される部分）には本来遷移したい次の画面、つまりはバリデーションエラーがなかった場合に進むべきstepを指定します。

何も問題がなければこのフォームデータ側のstepに画面は進んでいくことになります。

そしてsubmitボタンのnameにはそのデータを処理するpostモジュールの名前が書かれています。ここは普通に利用するときには決まったルール通りに記述すれば問題ありません。

となっています。

これらの指定の関係は図にするとこのような感じです。

f:id:nisyu:20141204141046p:plain

最初のstepと次のreapplyでの指定がreapplyとconfirmで一致しているのは、いずれの画面もエラーならreapplyであり、成功すればconfirmに進みたいからです。

そしてreapplyからconfirmへは一方通行ですのでaction側の指定はなくてかまいません。

独自にステップを増やしたりする場合は、特にこのようなルールを把握してくとよいでしょう。

・・・といったところでしょうか。最近詰まったというか、毎度フォーム周りで詰まるので、まとめてみましたが、あまりすっきりまとまってないな・・・そのうちもうちょっと綺麗に説明できるようにがんばります。

あ、他にも送信できなかった時に気をつけることとかあれば教えて下さい。

気づいたら、ここだった