なるほど!、動作確認できました。
わたしにはコードの修正しか思いつきませんでしたね。
Re: Tomoacさんの作成された機能拡張フォームについて(その2)
2011年7月2日 at 12:46
しらべたら、以下のHelperで出力されています。
$captcha = oader::helper('validation/captcha');
$captcha->display();
$captcha->showInput();
/concrete/helpers/validation/captch.php
を入れ替えればできると思います。
/helpers/validation/captch.php
におくべきですが、そこに置くとエラーになりました。
原因が分かれば教えていただけますか。
添付:
captcha.zip
Re: Re: Re: Re: Tomoacさんの作成された機能拡張フォームについて(その2)
2011年7月2日 at 14:09
Captchaの入力のとき強制的に半角になるようできましたので、Version 1.5.3 としてリリースしました。
http://concrete5.tomo.ac/osusumeblock/form/
http://concrete5.tomo.ac/osusumeblock/form/
1.5.3のバグ?
2011年7月4日 at 14:38
tomoac様はじめまして。
はじめてこの機能拡張フォームを知り、1.5.3をインストールさせていただきました。
すばらしいモジュールを提供いただきありがとうございます。
さっそくですが以下の症状を確認いたしました。
1.説明フィールドに入力しても値が保存されず、表示されない。
2.2重チェックメールアドレスフィールドに同じアドレスを入力しても、必須入力エラーが発生する。
環境
サーバ centos5.6 concrete5 5.4.1.1.1
クライアント winxp + firefox, osx + firefox, safari, opera
以上、よろしくお願いいたします。
はじめてこの機能拡張フォームを知り、1.5.3をインストールさせていただきました。
すばらしいモジュールを提供いただきありがとうございます。
さっそくですが以下の症状を確認いたしました。
1.説明フィールドに入力しても値が保存されず、表示されない。
2.2重チェックメールアドレスフィールドに同じアドレスを入力しても、必須入力エラーが発生する。
環境
サーバ centos5.6 concrete5 5.4.1.1.1
クライアント winxp + firefox, osx + firefox, safari, opera
以上、よろしくお願いいたします。
Re: 1.5.3のバグ?
2011年7月4日 at 21:58
>2.2重チェックメールアドレスフィールドに同じアドレスを入力しても、必須入力エラーが発生する。
これは添付を上書きいただくと解決すると思います。
>1.説明フィールドに入力しても値が保存されず、表示されない。
これはメールに限らず、おかしくなってますね。
今日はもう寝ます。「説明フィールド」の件はまたあした。
これは添付を上書きいただくと解決すると思います。
>1.説明フィールドに入力しても値が保存されず、表示されない。
これはメールに限らず、おかしくなってますね。
今日はもう寝ます。「説明フィールド」の件はまたあした。
添付:
controller.zip
Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月5日 at 15:09
form_setup_html.phpです。
メールフィールドの「編集」(どこのフィールドでも同じですが)を開き、
「説明」の入力が、選択フィールド、日付フィールド、テキストフィールド、メールフィールドの4つがあり、全部、DESC2 の名前にしていますが、「説明」のところを入力し「SAVE」すると、desc2の項目が空文字列でPOSTされるんです。結果、DBに保存されなくて表示もされない。
DBにphpMyAdminで書き込むと表示されるので、書き込みまでの問題であることはわかっています。
desc=desc2 でPOSTしていますので、controller.phpで、desc と書いてあるのは問題いありません。ただこれはこれでややこしいので、修正するつもりですが。
そこで、メールフィールドのところだけdesc3に変更すると、入力した文字がちゃんとPOSTされます。
同じ名前でも一回には、1フィールドの更新なので、問題なないはずなんですが、1フィールドだけの更新でも他のフィールドの<input が邪魔をしているようです。
メールフィールドの「編集」(どこのフィールドでも同じですが)を開き、
「説明」の入力が、選択フィールド、日付フィールド、テキストフィールド、メールフィールドの4つがあり、全部、DESC2 の名前にしていますが、「説明」のところを入力し「SAVE」すると、desc2の項目が空文字列でPOSTされるんです。結果、DBに保存されなくて表示もされない。
DBにphpMyAdminで書き込むと表示されるので、書き込みまでの問題であることはわかっています。
desc=desc2 でPOSTしていますので、controller.phpで、desc と書いてあるのは問題いありません。ただこれはこれでややこしいので、修正するつもりですが。
そこで、メールフィールドのところだけdesc3に変更すると、入力した文字がちゃんとPOSTされます。
同じ名前でも一回には、1フィールドの更新なので、問題なないはずなんですが、1フィールドだけの更新でも他のフィールドの<input が邪魔をしているようです。
Re: 1.5.3のバグ?
2011年7月5日 at 20:12
Re: Re: Re: 1.5.3のバグ?
2011年7月6日 at 13:52
Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月7日 at 16:09
郵便番号検索の件、メールでヒントを下さったからがおられ、中途半端のままだったことを思い出しました。
===========================================
"postno.cgi"の13行目の以下を
my $dbh = DBI->connect("dbi:mysql:dbname=concrete5_c5test1;host=localhost", 'concrete5', 'concrete5');
"/config/site.php"で合わせて変更してください。
define('DB_SERVER', 'localhost');
define('DB_USERNAME', 'concrete5');
define('DB_PASSWORD', 'concrete5');
define('DB_DATABASE', 'concrete5_c5test1');
以下のように置き換えてください。
変数は使えません中身に置き換えてください。
my $dbh = DBI->connect("dbi:mysql:dbname=<DB_DATABASE>;host=<DB_SERVER>", <DB_USERNAME>, <DB_PASSWORD>);
===========================================
このプログラムは、PHPに書き換える予定で、その際にデータベースの情報も
自動的に取得して動作するようにしたいと思います。
それとまだ事業者の郵便番号には対応していません。
ご希望があれば対応を急ぎますが。
===========================================
"postno.cgi"の13行目の以下を
my $dbh = DBI->connect("dbi:mysql:dbname=concrete5_c5test1;host=localhost", 'concrete5', 'concrete5');
"/config/site.php"で合わせて変更してください。
define('DB_SERVER', 'localhost');
define('DB_USERNAME', 'concrete5');
define('DB_PASSWORD', 'concrete5');
define('DB_DATABASE', 'concrete5_c5test1');
以下のように置き換えてください。
変数は使えません中身に置き換えてください。
my $dbh = DBI->connect("dbi:mysql:dbname=<DB_DATABASE>;host=<DB_SERVER>", <DB_USERNAME>, <DB_PASSWORD>);
===========================================
このプログラムは、PHPに書き換える予定で、その際にデータベースの情報も
自動的に取得して動作するようにしたいと思います。
それとまだ事業者の郵便番号には対応していません。
ご希望があれば対応を急ぎますが。
Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月7日 at 20:43
> 「郵便番号」の左の欄に「Searching...」と表示されたままになる
原因っぽいのが分かったような気がしますので報告させていただきます。
form_tomoac/block/form_tomoac/controller.php の中で CGI を呼び出しているところが、間違っているような気がします。
HTTPdのログ見たら
"GET /blocks/form_tomoac/postno.cgi?zip=~
を見に行っていました。
1111行目を以下のように変更したら動くようになりました。
httpObj.open("GET", "./packages/form_tomoac/blocks/form_tomoac/postno.cgi?zip=" + escape(zip), true);
原因っぽいのが分かったような気がしますので報告させていただきます。
form_tomoac/block/form_tomoac/controller.php の中で CGI を呼び出しているところが、間違っているような気がします。
HTTPdのログ見たら
"GET /blocks/form_tomoac/postno.cgi?zip=~
を見に行っていました。
1111行目を以下のように変更したら動くようになりました。
httpObj.open("GET", "./packages/form_tomoac/blocks/form_tomoac/postno.cgi?zip=" + escape(zip), true);
Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月8日 at 9:21
チェックボックスをグレーにする件
以下の変更でうまく動くと思います。
「form_setup_html.php 」
202行目
<br /><input id="mcheck2" name="mcheck2" type="checkbox" value="1" <?php echo (intval($miniSurveyInfo['notifyMeOnSubmission'])==0)?'disabled':''?> />
329行目
<br /><input id="mcheck2Edit" name="mcheck2Edit" type="checkbox" value="" <?php echo (intval($miniSurveyInfo['notifyMeOnSubmission'])==0)?'disabled':''?> />
「auto.js」
382行目あたり
showRecipient:function(cb){}
を
showRecipient:function(cb){
if(cb.checked)
{
$('#recipientEmailWrap').css('display','block');
$('#mcheck2').removeAttr('disabled');
$('#mcheck2Edit').removeAttr('disabled');
}
else
{
$('#recipientEmailWrap').css('display','none');
$('#mcheck2').attr('disabled','true');
$('#mcheck2Edit').attr('disabled','true');
}
}
以下の変更でうまく動くと思います。
「form_setup_html.php 」
202行目
<br /><input id="mcheck2" name="mcheck2" type="checkbox" value="1" <?php echo (intval($miniSurveyInfo['notifyMeOnSubmission'])==0)?'disabled':''?> />
329行目
<br /><input id="mcheck2Edit" name="mcheck2Edit" type="checkbox" value="" <?php echo (intval($miniSurveyInfo['notifyMeOnSubmission'])==0)?'disabled':''?> />
「auto.js」
382行目あたり
showRecipient:function(cb){}
を
showRecipient:function(cb){
if(cb.checked)
{
$('#recipientEmailWrap').css('display','block');
$('#mcheck2').removeAttr('disabled');
$('#mcheck2Edit').removeAttr('disabled');
}
else
{
$('#recipientEmailWrap').css('display','none');
$('#mcheck2').attr('disabled','true');
$('#mcheck2Edit').attr('disabled','true');
}
}
Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月8日 at 20:40
ありがとうございます。
早速組み込んで、Version 1.5.6 をリリースしました。
http://concrete5.tomo.ac/index.php?cID=81
メールフィールドでチェックした後、設定で解除した時、グレースケールになるもののチェックが入ったままとういのがちょっと気になるかも。
早速組み込んで、Version 1.5.6 をリリースしました。
http://concrete5.tomo.ac/index.php?cID=81
メールフィールドでチェックした後、設定で解除した時、グレースケールになるもののチェックが入ったままとういのがちょっと気になるかも。
Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月8日 at 9:27
tomoac様
「新着フォームのメール通知を受け取りますか?」の設定が
投稿者への確認メール発送へも有効とは認識しておりませんでした。
あらためて確認したところ、確認メールはちゃんと発送されていました。
申し訳ありません。
そこで新たな不具合?なのですが、
運営者宛てSubjectと投稿者宛てSubjectが別々に設定できますが
投稿者への確認メールもすべて運営者宛てSubjectで発送されております。
そのために、確認メールが未発送だと勘違いしていたようです。
ちなみに本文の方はちゃんと切り替わっているようです。
よろしくお願いいたします。
「新着フォームのメール通知を受け取りますか?」の設定が
投稿者への確認メール発送へも有効とは認識しておりませんでした。
あらためて確認したところ、確認メールはちゃんと発送されていました。
申し訳ありません。
そこで新たな不具合?なのですが、
運営者宛てSubjectと投稿者宛てSubjectが別々に設定できますが
投稿者への確認メールもすべて運営者宛てSubjectで発送されております。
そのために、確認メールが未発送だと勘違いしていたようです。
ちなみに本文の方はちゃんと切り替わっているようです。
よろしくお願いいたします。
Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月8日 at 20:41
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月15日 at 17:01
tomoac様
フォームの画面デザインについてなんですが、
見え方自体はテーマごとにCSSで設定するものなので、
ブロック側では、CSSで制御しやすいように、
HTMLの構造を統一し、HTML要素にクラスやIDを設定していただけると
助かります。
後ほど要望をさせていただこうかと思っていたことを述べます。
1.必須項目エラー時のメッセージには DIVタグにmsgクラスが指定されていますが、
内容確認や送信完了時のメッセージにはmsgクラスが指定されていないので、
指定して欲しいです。
2.送信等のボタンは、はじめテーブルの中に配置されていますが、
内容確認時のボタンはテーブルの外に配置されているので、
同じようにテーブル内に配置して欲しいです。
以上、よろしくお願いいたします。
フォームの画面デザインについてなんですが、
見え方自体はテーマごとにCSSで設定するものなので、
ブロック側では、CSSで制御しやすいように、
HTMLの構造を統一し、HTML要素にクラスやIDを設定していただけると
助かります。
後ほど要望をさせていただこうかと思っていたことを述べます。
1.必須項目エラー時のメッセージには DIVタグにmsgクラスが指定されていますが、
内容確認や送信完了時のメッセージにはmsgクラスが指定されていないので、
指定して欲しいです。
2.送信等のボタンは、はじめテーブルの中に配置されていますが、
内容確認時のボタンはテーブルの外に配置されているので、
同じようにテーブル内に配置して欲しいです。
以上、よろしくお願いいたします。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月16日 at 0:41
フォームのデザインについてはなんとかしたいと思っていますので、お教えいただければ対応いたします。
DIVタグにクラスやIDを設定すると、CSSでデザインを変更できることはわかります。ただ、デザインの自由度の幅を広げるために、どのようにDIVタグでくくればいいのかなどのノウハウがありません。
また、Concrete5の多くのマーケットプレースなどで提供されているデザインテンプレートを利用した時でも、そのテーマでデザインが変わることが望ましいと思います。すると、標準化されたIDを付けるべきだと思います。そのような仕組みなのかどうかもわかりませんが。
また、関係あるのかどうなのかもわかっていないのですが、ブロック毎にテンプレートが定義できますが、そのテンプレートでもデザイン変更ができるのではと思って調べています。
ぼちぼち勉強しますが、教えていただければ早く対応できます。
とりあえずこうしてくれないか、ということであれば、具体的にここにDIVタグをいれて、この名称のIDを付加してほしいと具体的に言っていただければ対応します。
DIVタグにクラスやIDを設定すると、CSSでデザインを変更できることはわかります。ただ、デザインの自由度の幅を広げるために、どのようにDIVタグでくくればいいのかなどのノウハウがありません。
また、Concrete5の多くのマーケットプレースなどで提供されているデザインテンプレートを利用した時でも、そのテーマでデザインが変わることが望ましいと思います。すると、標準化されたIDを付けるべきだと思います。そのような仕組みなのかどうかもわかりませんが。
また、関係あるのかどうなのかもわかっていないのですが、ブロック毎にテンプレートが定義できますが、そのテンプレートでもデザイン変更ができるのではと思って調べています。
ぼちぼち勉強しますが、教えていただければ早く対応できます。
とりあえずこうしてくれないか、ということであれば、具体的にここにDIVタグをいれて、この名称のIDを付加してほしいと具体的に言っていただければ対応します。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月16日 at 8:10
masnogさんへ
確認画面と送信後画面のことをおっしゃられているのではないかと思うのですがあっていますでしょうか?
お手数ですが、僕もよくわかっていなくて・・・・すみません。
そこで3つのファイルを添付させていただきました。
それぞれ、formタグの中身のみを取り出したものです。できればこのファイルに書き加えてアップしていただけませんでしょうか?そうすればわかりやすいと思います。よろしくお願いします。
tomoacさんへ
現在のブロックは次期バージョンの5.4.2では動きません。
jquery関係の仕様変更が問題のようです。
その他いろいろ教えていただきたいこともございますので、
一度二人ででも、お会いするかして勉強会をしませんか?
ご返事待っています。
確認画面と送信後画面のことをおっしゃられているのではないかと思うのですがあっていますでしょうか?
お手数ですが、僕もよくわかっていなくて・・・・すみません。
そこで3つのファイルを添付させていただきました。
それぞれ、formタグの中身のみを取り出したものです。できればこのファイルに書き加えてアップしていただけませんでしょうか?そうすればわかりやすいと思います。よろしくお願いします。
tomoacさんへ
現在のブロックは次期バージョンの5.4.2では動きません。
jquery関係の仕様変更が問題のようです。
その他いろいろ教えていただきたいこともございますので、
一度二人ででも、お会いするかして勉強会をしませんか?
ご返事待っています。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月17日 at 8:57
すみません。
先の書き込みをするさいに書き込みがあることに気付きました。
お手数でした。
勉強会の件
すみません。実はいまの会社を辞めることにしたので時間もあったのですが、新しいところに仕事を持っていって引き継ぐことになりそこでしばらくお手伝いすることになったことがあり、ちょっと時間がとれません。8月中旬以降になったら落ち着くかもしれません。
バグ修正等は、逆に気分転換として適当な時間なので対応はさせていただいてます。
先の書き込みをするさいに書き込みがあることに気付きました。
お手数でした。
勉強会の件
すみません。実はいまの会社を辞めることにしたので時間もあったのですが、新しいところに仕事を持っていって引き継ぐことになりそこでしばらくお手伝いすることになったことがあり、ちょっと時間がとれません。8月中旬以降になったら落ち着くかもしれません。
バグ修正等は、逆に気分転換として適当な時間なので対応はさせていただいてます。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月17日 at 8:45
具体的にご指摘いただいたところを修正しました。
ご指摘の後、ソースを見ていましたら、ご指摘の意味がわかりました。
Version 1.5.7 としてリリースします。
http://concrete5.tomo.ac/osusumeblock/form/
id="msg"は、エラーメッセージなので、エラーでないメッセージ用に、id="msg2" にしました。
classの指定は必要ですか?
私には意味や用途が分からないもので。
ご指摘の後、ソースを見ていましたら、ご指摘の意味がわかりました。
Version 1.5.7 としてリリースします。
http://concrete5.tomo.ac/osusumeblock/form/
id="msg"は、エラーメッセージなので、エラーでないメッセージ用に、id="msg2" にしました。
classの指定は必要ですか?
私には意味や用途が分からないもので。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月19日 at 10:08
tomoac様
テーマの変更に拡張フォームブロックの外観も統一するためには、
標準フォームブロックの構造やクラスを継承するのが一番だと思います。
なぜなら、標準のフォームブロックで使用されているクラスやIDのスタイルであれば
テーマ内のcssで指定されている可能性が高いからです。
標準フォームブロックの構造、クラス、IDをまとめてみました。
1.先頭にアンカータグを配置
2.アンカー以下のブロック全体をformブロックで囲んでいる
formのIDは "miniSurveyView"+bID 、クラスは"miniSurveyView"
3.目に見えるフォーム要素はテーブル内に配置
tableにはクラス"formBlockSurveyTable"を指定
4.左のtd(class="question")に質問の見出しを表示
右のtd(classなし)にフォーム要素を配置
5.テーブル最下行の右側tdに、submitボタンを配置
6.完了やエラーメッセージはform最上部にdivタグ(id="msg")内に配置
7.エラーメッセージはさらにdivタグ(class="error")で囲まれている
拡張フォームブロックは標準フォームブロックをベースに開発されているので
上記のほとんどはそのままなのですが、独自に拡張された部分がこれらのルールから
はずれている箇所があります。
それが前回あげさせていただいた、以下の2点です。
・id="msg"が指定されていないメッセージがある
・送信等のボタンがテーブル内に配置されていない。
また、今回"msg2"というidを増やされましたが、そうではなく(7)のように
エラーメッセージをdivタグ(class="error")で囲むのがベターです。
ちなみにIDとクラスについてですが、機能は似ていますが、その違いは、
IDはページ内で必ずユニークな要素ですが、クラスの方は同じクラスの要素が
複数あっても構わないモノです。
今、"msg"はidで指定していますが、本来はクラスで指定するべきだろうと思います。
以上、よろしくお願いいたします。
テーマの変更に拡張フォームブロックの外観も統一するためには、
標準フォームブロックの構造やクラスを継承するのが一番だと思います。
なぜなら、標準のフォームブロックで使用されているクラスやIDのスタイルであれば
テーマ内のcssで指定されている可能性が高いからです。
標準フォームブロックの構造、クラス、IDをまとめてみました。
1.先頭にアンカータグを配置
2.アンカー以下のブロック全体をformブロックで囲んでいる
formのIDは "miniSurveyView"+bID 、クラスは"miniSurveyView"
3.目に見えるフォーム要素はテーブル内に配置
tableにはクラス"formBlockSurveyTable"を指定
4.左のtd(class="question")に質問の見出しを表示
右のtd(classなし)にフォーム要素を配置
5.テーブル最下行の右側tdに、submitボタンを配置
6.完了やエラーメッセージはform最上部にdivタグ(id="msg")内に配置
7.エラーメッセージはさらにdivタグ(class="error")で囲まれている
拡張フォームブロックは標準フォームブロックをベースに開発されているので
上記のほとんどはそのままなのですが、独自に拡張された部分がこれらのルールから
はずれている箇所があります。
それが前回あげさせていただいた、以下の2点です。
・id="msg"が指定されていないメッセージがある
・送信等のボタンがテーブル内に配置されていない。
また、今回"msg2"というidを増やされましたが、そうではなく(7)のように
エラーメッセージをdivタグ(class="error")で囲むのがベターです。
ちなみにIDとクラスについてですが、機能は似ていますが、その違いは、
IDはページ内で必ずユニークな要素ですが、クラスの方は同じクラスの要素が
複数あっても構わないモノです。
今、"msg"はidで指定していますが、本来はクラスで指定するべきだろうと思います。
以上、よろしくお願いいたします。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月19日 at 11:05
ご教示ありがとうございます。
すみません。結果、どうなんでしょう?
>拡張フォームブロックは標準フォームブロックをベースに開発されているので
>上記のほとんどはそのままなのですが、独自に拡張された部分がこれらのルールから
>はずれている箇所があります。
>
>それが前回あげさせていただいた、以下の2点です。
これは解決しましたでしょうか?
>また、今回"msg2"というidを増やされましたが、そうではなく(7)のように
>エラーメッセージをdivタグ(class="error")で囲むのがベターです。
msg2は、エラーでなく単なるメッセージなので、エラーと同じにはしなかったのですが、divタグ(class="error")で囲むほうがいいでしょうか。
>ちなみにIDとクラスについてですが、機能は似ていますが、その違いは、
>IDはページ内で必ずユニークな要素ですが、クラスの方は同じクラスの要素が
>複数あっても構わないモノです。
>今、"msg"はidで指定していますが、本来はクラスで指定するべきだろうと思います。
classで範囲を限定することで、同じネイ省のID名の重複を避けるということでしょうか。
すみません。結果、どうなんでしょう?
>拡張フォームブロックは標準フォームブロックをベースに開発されているので
>上記のほとんどはそのままなのですが、独自に拡張された部分がこれらのルールから
>はずれている箇所があります。
>
>それが前回あげさせていただいた、以下の2点です。
これは解決しましたでしょうか?
>また、今回"msg2"というidを増やされましたが、そうではなく(7)のように
>エラーメッセージをdivタグ(class="error")で囲むのがベターです。
msg2は、エラーでなく単なるメッセージなので、エラーと同じにはしなかったのですが、divタグ(class="error")で囲むほうがいいでしょうか。
>ちなみにIDとクラスについてですが、機能は似ていますが、その違いは、
>IDはページ内で必ずユニークな要素ですが、クラスの方は同じクラスの要素が
>複数あっても構わないモノです。
>今、"msg"はidで指定していますが、本来はクラスで指定するべきだろうと思います。
classで範囲を限定することで、同じネイ省のID名の重複を避けるということでしょうか。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月19日 at 13:47
tomoac様
1.5.7確認をいたしました。
ちなみに修正の観点は、標準フォームブロックの構成に近づけることであって
良い悪いとは別問題だということをご承知ください。
>これは解決しましたでしょうか?
ありがとうございます、ほぼOKなのですが、ボタンを配置する最下行のtrにtdがひとつになっているのと、
不要なbrタグがはいっています。
<tr>
<td colspan="2"><input type="hidden" name="state" value="2"><br />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="送信する" />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="戻って修正する" /></td>
</tr>
↓
<tr>
<td> </td>
<td>
<input class="formBlockSubmitButton" name="Submit" type="submit" value="送信" />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="戻って修正する" />
</td>
</tr>
>msg2は、エラーでなく単なるメッセージなので、エラーと同じにはしなかったのですが、
>divタグ(class="error")で囲むほうがいいでしょうか。
メッセージを囲むdivのIDは"msg2"→"msg"に変更して欲しいです。
そうでないと、id="msg2"へのcssスタイルをテーマに追加する必要が発生します。
メッセージのhtml構成は以下のように整理されればよろしいかと
<div id="msg">
ここに普通のメッセージ
<div class="error">ここにエラーメッセージ</div>
<div class="error">ここにエラーメッセージ2</div>
</div>
>classで範囲を限定することで、同じネイ省のID名の重複を避けるということでしょうか。
いえ、IDは必ず一意でなければならないのに、"msg"なんてありきたりな名前をつけるのは
重複する可能性が高いため不適切なID名だと思っています。
concrete5的には、formのid "miniSurveyView"+bID のように bID を加えたID名にする
のがベターかなと思います。
1.5.7確認をいたしました。
ちなみに修正の観点は、標準フォームブロックの構成に近づけることであって
良い悪いとは別問題だということをご承知ください。
>これは解決しましたでしょうか?
ありがとうございます、ほぼOKなのですが、ボタンを配置する最下行のtrにtdがひとつになっているのと、
不要なbrタグがはいっています。
<tr>
<td colspan="2"><input type="hidden" name="state" value="2"><br />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="送信する" />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="戻って修正する" /></td>
</tr>
↓
<tr>
<td> </td>
<td>
<input class="formBlockSubmitButton" name="Submit" type="submit" value="送信" />
<input class="formBlockSubmitButton" name="Submit" type="submit" value="戻って修正する" />
</td>
</tr>
>msg2は、エラーでなく単なるメッセージなので、エラーと同じにはしなかったのですが、
>divタグ(class="error")で囲むほうがいいでしょうか。
メッセージを囲むdivのIDは"msg2"→"msg"に変更して欲しいです。
そうでないと、id="msg2"へのcssスタイルをテーマに追加する必要が発生します。
メッセージのhtml構成は以下のように整理されればよろしいかと
<div id="msg">
ここに普通のメッセージ
<div class="error">ここにエラーメッセージ</div>
<div class="error">ここにエラーメッセージ2</div>
</div>
>classで範囲を限定することで、同じネイ省のID名の重複を避けるということでしょうか。
いえ、IDは必ず一意でなければならないのに、"msg"なんてありきたりな名前をつけるのは
重複する可能性が高いため不適切なID名だと思っています。
concrete5的には、formのid "miniSurveyView"+bID のように bID を加えたID名にする
のがベターかなと思います。
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月19日 at 15:08
> ありがとうございます、ほぼOKなのですが、ボタンを配置する最下行のtrにtdがひとつになっているのと、
> 不要なbrタグがはいっています。
ボタンの行はカラムが1列がいいと思って、colspan=2にしてtdを一つにしました。教えていただいたようにすると、ボタンが右に寄りますが、それがいいという意味でしょうか。
brはとります。
> メッセージを囲むdivのIDは"msg2"→"msg"に変更して欲しいです。
> そうでないと、id="msg2"へのcssスタイルをテーマに追加する必要が発生します。
評判の悪い、msg ですが、元のソースがmsgだったのでそのままにしています。
変更すると、formとの互換性に問題が出るかと思っていてそのままにしています。
msg2 のことはわかりました。エラーは<div class="error">で見た目が変えられるんですね。msg2, msg3 もmsg にします。
直接関係ありませんが、このさい教えてほしいですが、一口でいえばclassとidはどういう基準で使い分けるんですか?
> 不要なbrタグがはいっています。
ボタンの行はカラムが1列がいいと思って、colspan=2にしてtdを一つにしました。教えていただいたようにすると、ボタンが右に寄りますが、それがいいという意味でしょうか。
brはとります。
> メッセージを囲むdivのIDは"msg2"→"msg"に変更して欲しいです。
> そうでないと、id="msg2"へのcssスタイルをテーマに追加する必要が発生します。
評判の悪い、msg ですが、元のソースがmsgだったのでそのままにしています。
変更すると、formとの互換性に問題が出るかと思っていてそのままにしています。
msg2 のことはわかりました。エラーは<div class="error">で見た目が変えられるんですね。msg2, msg3 もmsg にします。
直接関係ありませんが、このさい教えてほしいですが、一口でいえばclassとidはどういう基準で使い分けるんですか?
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 1.5.3のバグ?
2011年7月19日 at 17:44
>ボタンの行はカラムが1列がいいと思って、colspan=2にしてtdを一つにしました。
>教えていただいたようにすると、ボタンが右に寄りますが、それがいいという意味でしょうか。
どちらがよいとかではなく、最初の送信フォームのボタン配置がそうなっているので
統一するならという程度の理由です。
>評判の悪い、msg ですが、元のソースがmsgだったのでそのままにしています。
>変更すると、formとの互換性に問題が出るかと思っていてそのままにしています。
はい、 標準フォームとの互換性のために、そのままにするほうがよいと思います。
>msg2 のことはわかりました。エラーは<div class="error">で見た目が変えられるんですね。
はい、ちなみに私はcssで、クラスがerrorなdivは赤く強調した表示に指定しています。
>直接関係ありませんが、このさい教えてほしいですが、一口でいえばclassとidはどういう基準で使い分けるんですか?
まず、idとクラスの違いは、先に述べたとおりidはページ内で一意でなければなりません。
そのため、idはページ内に必ず一度しか現れない要素に指定します。
例)ヘッダー、フッター、サイドバーなど...
複数表れる要素にidを指定する場合は、重複しないシリアル番号を付加したid名にします。
例)msg0001, msg0002...
で、具体的にどのような違い(効果)があるかというと
1.スタイルシートでの優先順位(重み付け)が違い、idでの指定が最優先です。
局所的にスタイルを変更したいような場合には、idを使うことがよくあります。
2.idを指定することで、javascriptなどで要素を一発で取り出し可能です。
値の読み書きや、表示のオンオフをしたい要素には、よくidを指定します。
3.idはページ内の位置指定にも使えます。<a href="#header">ページ先頭へ</a>
このような効果が欲しい場合にはidを使います。
>教えていただいたようにすると、ボタンが右に寄りますが、それがいいという意味でしょうか。
どちらがよいとかではなく、最初の送信フォームのボタン配置がそうなっているので
統一するならという程度の理由です。
>評判の悪い、msg ですが、元のソースがmsgだったのでそのままにしています。
>変更すると、formとの互換性に問題が出るかと思っていてそのままにしています。
はい、 標準フォームとの互換性のために、そのままにするほうがよいと思います。
>msg2 のことはわかりました。エラーは<div class="error">で見た目が変えられるんですね。
はい、ちなみに私はcssで、クラスがerrorなdivは赤く強調した表示に指定しています。
>直接関係ありませんが、このさい教えてほしいですが、一口でいえばclassとidはどういう基準で使い分けるんですか?
まず、idとクラスの違いは、先に述べたとおりidはページ内で一意でなければなりません。
そのため、idはページ内に必ず一度しか現れない要素に指定します。
例)ヘッダー、フッター、サイドバーなど...
複数表れる要素にidを指定する場合は、重複しないシリアル番号を付加したid名にします。
例)msg0001, msg0002...
で、具体的にどのような違い(効果)があるかというと
1.スタイルシートでの優先順位(重み付け)が違い、idでの指定が最優先です。
局所的にスタイルを変更したいような場合には、idを使うことがよくあります。
2.idを指定することで、javascriptなどで要素を一発で取り出し可能です。
値の読み書きや、表示のオンオフをしたい要素には、よくidを指定します。
3.idはページ内の位置指定にも使えます。<a href="#header">ページ先頭へ</a>
このような効果が欲しい場合にはidを使います。
Your post has been saved and will be published after approval by the forum moderator.
みゅみゅ
Re: Re: Tomoacさんの作成された機能拡張フォームについて(その2)
CSSですのでview.cssに下を入れれば解決するよう気がします。
input.ccm-input-captcha {
ime-mode:inactive
}