フラメンコに関すること、フェスティバル・デ・ヘレスに関することを書き散らしています。ヨロシクね。
2018年11月05日 (月) | 編集 |
まだ「お問合せフォーム」にかかずらっています。
久々にメール送信プログラムを書いているんだけど
いろいろ新しくなっていて、いちいち時間かかる~

メール送信部分と、入力エラーチェック部分は2日前に書き終わった。
テスト送信したメールヘッダを見たところ、つつがなくDKEYもセットされていた。
SPFレコードは独ドメメアドの利用開始時から設定していたし
これで迷惑メールに放り込まれることもなかろう。ふぅ。

フォームメールてわけで、入力エラーがあったときの画面作成。こんな具合に入力項目はすくないし、これはパルマ教室用だから「人数」を記入する項目があるけど、それいがいの総合インフォ的なざっくりした「問い合わせ用」だと人数なんて項目もないからもっと小さくなる。スマホだけ相手にするんならメールフォームだけのページに飛ばしちゃってもいんだけど、PCやタブレットと画面を共有するレスポンシブサイトだから、大画面にメールフォームだけってのは間がぬーけーるー(苦)。

ページキャプチャちゅうわけで、かようにページの一部に埋め込みました。明らかな記入エラーがあったばあい(はいここ大事。姓名のあいだに見えなような小文字のLが挟まっているようなメールでも受け取ってしまう方向で運用します。読むのは人間なので問題ないです。)、また1から入力させるのは手間なので申し訳ないし、、、つか、「あんだよっ、メンドクセーなっ(怒)!」って問い合わせの送信自体やめちゃうかもしれないので(汗)、記入した項目は維持して「ここがヘンだよ日本人」的エラーメッセージを出しつつ、おかしな所だけ記入し直してもらうのが一般的。

メールフォームだけの単独ページでも
フォーム部品に記入済みの内容をセットしてリダイレクトしなくちゃならない。
面倒くさいっちゃ面倒くさいんだけど
それを言ったらどんなプログラムも面倒くさくてやる気でなくなるので言わない約束。

ただ、ページの一部を
記入済み項目で埋めたフォーム部品でアップデートして書き換えるのがちと面倒。

JavaScriptでエラーチェックも再描画もやっちゃう
これが一番エレガント。
JavaScriptなんでクライアントサイド(=ブラウザ上)で動作するから
サーバーとの通信も、データの転送も起きない。
時短だし、省トラフィック(=省パケ)。
エラーならフォーム部品に記入済み項目をセットしたフォームを組み立てて
エラーメッセージと一緒にinnerHTMLで再描画させるだけ。
2000年頃には激ポピュラーだったDynamicHTML。
でも、ひとまず公開したら人知れずしこしこ手をいれて
AMP(Accelerated Mobile Pages)対応するつもりなのでJavaScriptはNG。
好きなJavaScriptをAMPで実行できるようになるかも。Web Workerで実現か?
なんて記事を見つけたけど、先になりそうなので
今から書くAMPページではNGとおもって書くのが正解。
だいいちDOMアクセスできないんじゃ、DHTMLできないし
そのうちDOMアクセスにも対応させるかもしれないんだって。
その頃には墓にはいっているとは言わないケド
脳ミソは死んでいると思うからどーなろーと知ったこちゃありまへん

PHPのfopen()とforeach()と正規表現でやっていた手法
JavaScriptでやるのがトラフィック的にはエレガントなんだけど
ソースコードは汚い。
 ・エラーメッセージ付きで表示する記入済みフォーム部品と
 ・はじめましてな空っぽフォーム部品
って、フォーム部品に初期値がセットされているかないの差でしかない
まったくおなじHTMLコードだから
JavaScriptソースのほうにフォームhtmlを書いて
いつなんどきでもJavaScriptでdocument.writeしちゃうのがスッキリさん。
そして時短、省パケなお利口さん。
ただ、htmlソースがJavaScriptソースにお引越ししているんで見通しわるい。
ソースが汚い。
あたしが書くていどの小規模ウェブサイトなんて
あんまり気にしなくていいレベルなんだけど
そこは性分なんで汚いのはイヤ。
回線速度とパケ通信費がいいカンジになったタイミングで
CGIスクリプトで処理する方式に変えた。

ただねぇ、、、やってることは
 ・htmlファイルを全読みして
 ・foreach()でちんたら回してフォーム部品を拾い
 ・記入済みテキストをセットしたフォーム部品に書き換えて
 ・サーバーからブラウザに投げる
って仕組みなんで
フォームを書き替えたらforeach()から強制離脱するけど
それにしたって多少かったるいつか、ローテクで気分落ちるつか、、、。

PHPのDOMDocument
そんなあたしに朗報
コードの書き方を調べていると2006年とか2005年とか
くっそ古いブログ記事がみつかるので、けっこう枯れたテクニックらしいんだけど
そのころにはPHPなんて書いてないので知りませんでした。
CMS用のプラグインくらいは書いた気がするけど
DOM操作を伴うようなのは書いてないからまったく知らなかった。

そうDOMを扱えるライブラリ
DynamicHTML的な書き方でページの書き換えができるのね~
でも、そこはPHPなので
書き換えたhtmlをsaveしてブラウザに投げるしかない。
ブラウザ的にはド頭から再レンダリングするわけだし
パケット通信的にも全htmlをまたぞろ丸々受け取るアンチ省パケ。
みなさん、メール送信フォームに記入するときには
なるべくエラーにひっかからないよう慎重にキチンを記入しましょう。
お洋服の通販サイトとかも含めて商用サイトなんて
庶民の味方のわけはなく
おそらくは無駄な通信費を払わせてでも
経済をまわすほうの設計をしていると思います。
うがった見方ですけど、ネ。

ともあれ、ウチのサイトなんてhtmlのサイズは極小ですし
パケット通信費もぐっと安くなって、回線速度も十分早いことですし
な~んも気にすることなくサーバーとの通信をしていい範疇です。
PHPライブラリのDOMアクセスを使っても
内部的にはhtmlファイルをだ~っと読み下して
フォーム部品を拾ってるに決まってますが
その部分を高速な言語で書いているハズなので(?)
foreach()でちんたらまわしているのとはモノが違うハズです
おしおし。使っちゃる

、、、って、まぢかよ~!!??
html5に対応してねぇ~
loadHTML()したら
html5で書いているのにhtml4のヘッダを付加してくださるらしい。
クソい! いらんことすな!
loadXML()すると<root></root>なんていらないタグついちゃうけど
<meta>タグへの「汚染」は防げるってブログ記事を発見
phpのDOMDocumentで断片的なhtmlを扱うならxmlとして読み込むのがよさそう(PHP Advent Calendar jp 2010 Day 23++)
しか~しっっ、xmlなので
<input>とか、<meta>とか、<img>とか、、、etc
ウェブサイトを構築するのに使わないわけないタグの
タグの閉じタグがないってパースエラーを吐くらしい
あるときからXHTMLに移行してるから
このブログに画像やらのhtmlコードを直書きするときも
習慣で<img src="---" />的にタグ閉じしてるけど、、、
<header>だの、<article>だの、<footer>だの、<nav>だの
新しくできたタグを積極的に使いまくってるんですが~、、、。
<div>にclassだのidだの書いて文書構造をわかりやすくするのは鉄則として
専用のタグがあるならそっち使ったほーがマークアップ的によろしいかと思うじゃん。
でも、そんなもんはhtml4では定義してないハズなんで
html4時代のxmlでパースエラー吐かない気がしない、、、
まぢか~。
エラー吐いても気にせず処理してくれるならいいけど
パースエラー吐くときは律儀にブラウザにエラー吐いて処理止まるみたい、、、
正気か~。

使えないじゃん。
ってコトを知るまでにまた2日消費した
だってコードの書き方わからなかったから
いきあたりばったりでコード探して、眺めて
なんとなく使い方がわかったから
改めて必要なことを深堀して調べて知ったんだもん
PHPのマニュアルなんて頭から律儀に読んでられっかよ!!
でも、そーすべきだった。

結局、foreach()でまわすローテクでいきます(しおしお)。
それか嫌いだけどiframeタグ使おうかなぁ~。
トライデントことクソIEが4とか5とかの時代に
仕様先取り(つか仕様無視)で実装して
<blink>並みにクソタグって認識になってるから
仕様が決まって大方のブラウザで実装するようになった今でも
クソタグって認識から抜けられなくてキライなんだよな~。
でもAMPでもiframeは実装してるみたいなんで問題ないや。
、、、使うか、、、。
ホント、クソIEは罪深いわっ。

2016年10月28日 (金) | 編集 |
コンパネの作りから、CMSスクリプトの動作原理を把握しやすいぞ。
ポーランド製らしい。
日本人やドイツ人に通じる、コンテンツ管理の設計がクリアな思考回路らしい。

おそらくTypesetter CMSは香港製。
大陸的な、表面的なものにこだわるツメの甘い思考回路で作られたっぽい。
香港は日本より小さな島国だったけど、もう大陸に返還されたし
人民のメンタリティがどうしても大陸的なんだと思う。
とにかくコンパネの設計が悪すぎる。
コンテンツを管理するまえに
コンパネの突貫工事的ユーザーインターフェースを理解すのがダルい。
思考回路やら嗜好回路がちがいすぎてキツいわ。
2バイト文字対応はぜったいこっちのほうが上なんだけど、、、。
使いにくい道具に四苦八苦してつきあうんじゃ本末転倒なんでナシだな。

よし、Quick.cmsでいくか!

機能がシンプルすぎて
イベント告知みたいなヘッドラインを時限公開する仕組みはないっぽい。
つまり
 ・イベントが終了したら手動でその部分のコンテンツを非表示にするか
 ・イベント告知用のプラグインをコーディングするか
ってコトになりそうな雲行き。
ま、高機能でもスパゲティ状態のひっからまったシステムにつきあうくらいなら
コード書いちゃうほうが好みではあるからそんなに面倒くさくないし。いっか。

おそらくこの調子でCMSにあってほしい機能が軒並みない雲行き(汗)。
純粋にコンテンツ管理しかしないっぽい。
帯に短し、襷に流しだなぁ~。
もうあまりあれこれテストしてる時間はないから
この激スッキリしたインターフェースのCMSでやりくりしてみる(押忍っ)
2016年10月28日 (金) | 編集 |
そうなんです。
あたしいっつもあれもこれもやっているんです。
しかも、手をだしてしまえば実労働半日以下なことだったりするんだけど
それはハマってから後悔しないように念入りに下調べをするからだったりする。

こんどはコンテンツマネジメントシステムです。
こっちはホント言って緊急だったりする。
わけあってスタジオのサイトを丸ごと構築し直すのである。

焦って選定をミスるとサーバーへのシステムインストールやら
作ってしまったコンテンツの再作成やら
データベースから手作業でコンバートしたデータの作り直しやら
二重手間になる要素が多すぎるので、めちゃくちゃ慎重にやってます。
でも、そろそろ決めて手をつけないとマズい時期。

このブログの記事素晴らしい!
なるほど~、コンテンツを1ファイルで管理するんだね!
、、、って、、、
うちのサイト、それなりに画像つかって凝ったレイアウトにしてるから
ブロッキング構造が複雑だし、1ページ当たりのhtmlがわりと長大だぞ(汗)。
こんなにスマホが普及するまえはね~
なるべくスクロールなしでコンテンツが見渡せるほうがいいってのが主流だったの。
だからブロッキングしてなるべく1024x768なモニタに全要素をぶっこんでたの。
スマホのばあいは、スクロールがあってもかまわなくて
それよりむしろ画面幅が狭いから複雑なレイアウトにしないほうがよいのだ。
いいかげん時代にあわせてレイアウトは変更するつもりだったからいんだけど、、、
それにしたって全コンテンツを1ファイルは動作速度が不安だわ。
そして、このブログに書いてあるようにSEO的にめちゃくちゃ不利!!
こういうシステムの内部処理を書いておいてくれる記事は超ありがたい。
見習いたいものです。

じつは、もう一歩で
CMSimpleをローカル環境にインストールしてテストするところだった。
無駄をせずにすんだ。

あいにくこのブログみたいな記事がみつからないので
ぢぶんでテストせざるを得ないんだけど
typesetter CMSってのいってみる。
ちょっと急がなくちゃいけないから、時間がムダにならないとい~なぁ。



■6:35追記
ムダにしたっぽい。
どうにもこうにもわからなくはないけど、やっぱ機能盛りすぎ。
そして直感的操作にこだわるあまり、フロートする編集用のメニュー多すぎ。
さながらPhotoShopの使い方を1時間でおぼえろ! なカンジ。
使いにくいな~。
あと、インターフェースの設計思想がどうも肌にあわない。
キチンと設計してない突貫工事システムな部分もあるし、、、。
あとから付け足したみたいに辺なところにヘッダメニューの追加機能がある。

でも、最悪こいつを乗りこなすという選択肢もまだのこっている。

も、さぁ
ブログスクリプトをCMSって呼称すんのやめてくれないかなぁ。
CMSかと思ったら、たんなるブログスクリプトなんで使えない。
ブログスクリプト・トラップにひっかかって選定に時間かかって仕方ない。

2015年09月16日 (水) | 編集 |
おんやぁ~??? なんじゃこりゃ。

もちろんこんなのが起動すると思ってましたとも。
ちゅか、インターフェースもほぼこのまんまなスクリプトをちゃちゃっと書いて
コードの表示チェックをしながら仕事をすすめるつもりでした。
そら、需要あるわなぁ。
ブラウザに標準で実装しといても邪魔でもなんでもないわなぁ。
FireFox、ホントにいつもありがとう。
君はいつだってウェブデベロッパの味方だね。

ところで、このツールは
キャッシュの扱いがちょっとだけおバカかも。
解像度を変更してスタイルシートがちゃんと切り替わるかチェックしたいのに
たま~にリロードしそこなってるぽい。
ホントはコードあってたのに
こいつの反応が修正前のコードで実行しやがるんで
コードがまちがってるのかと、分岐条件を穴があくほど眺めてしもたげな。
「●●ピクセル以上、●●ピクセル以下ならこのスタイルシート」
みたいな条件分岐って
あたし粗忽なので、以上と以下を反対に書いちゃったりして
ちょいちょいハマるんだわ~

あたしが不注意すること多めなポイントなので
FireFoxまで苦手だとにっちもさっちもいかないちゅーの(笑)。
たのんますわ~。

ちなみにスタイルシートピクセルと、viewportピクセル(ちゅーの?)は1対1なので
スマホ実機で表示したときみたいな文字の拡大はしません。
あたりまえ。
あくまでレイアウト(=ブロッキング)のチェック用です。

2015年09月11日 (金) | 編集 |
「ドキュメントを読む」なんて書いちゃうと
英語のreadmeとかmanualを読んでいるみたいな
ムダにカッコいいイメージを持っちゃいますが、、、って、あたしだけ?
node.jsのことを書いてある初心者カモーン的なページを読んでいるだけです。

以前ちょこっと node.js に関心をもったときに
どうやらインストールが必要だってことがわかったので
レン鯖にインストールできなかったらローカルで遊ぶだけって思った。
コード書いて楽しいとかゆー風流な生活はできなくなりすぎているので
レン鯖にインストールして実稼動させられないならスルー!
と、すっかり関心を失っていました。
サポートしないから格安で鯖で貸したるんで実験大歓迎!
ってのがコンセプトのxrea
ならシェルに入れるのでインストールできると思ったけど
 ※そーなんですよ。
 小遣いが少ないガキんちょ専用サーバーみたいに思われているかもしれないけど?
 金ははくても向学心のある学生君に使わせる! ってのがコンセプトなんですよ。
無料アカウントじゃ使用可能容量が少なすぎるので
(データベースと合わせて2GBとかだっけかな? 忘れた)
有料契約してまで実験したいと思わずスルー。
ロリポップの空きディスク容量がたっぷりあるから
node.js をインストールできたらよかったんだけどねぇ、、、、。ダメです。

ってあたりで調べるのもやめちゃっていたんだけど、、、
node.js ってnode.jsのモジュールみたいなカンジでhttpサーバーを記述できるのね。
てっきりApacheのモジュールかなんかで実装するのかとテキトーに推測してた。
そしてブログにそのまんま書いてしまって、いますっごく恥ずかしい気分です。

しかし、時間が経過してるだけのことはある。
あたしみたいなトーシローでもアカウント取るだけで実行環境を使えるようになってた!
基礎から学ぶnNode.js
Azure Websites を Node.js PaaS として使う
どっちもマイクロソフトのクラウドプラットフォームを使う説明。
あらま、楽ちんそー。

環境は無料かつ、ほいちょいで手にはいることはわかった。
あとはあたしのスキル(T^T)、、、。
よーはこれまでPHPやPerlで書いたことがあるようなサーバーサイドスクリプトを
Javascriptで書かなくっちゃいけないんでしょ。
クライアントサイドのJavascriptはそこそこコーディングできるけど
サーバーサイド用となると、見たことも聞いたこともない関数を使わなくっちゃ。
新しい言語を習得するのとハードル的にはあまり変わらない状況
しかも、ちょいちょい目にはいってくるコードが
これまで1回も書いたことないJAVAのスタイルにそっくりなんだよなぁ。
「オブジェクト指向」的なコーディングに見える~~(涙)。
「オブジェクト指向」わかんね~ 理解できね~
だ、だいじょぶか? あたし?

でも、とりあえず楽しいので調査続行。
node.js製のCMSのコードをいくつか見てみて
ぢぶんでプラグイン書けそうか感触をさぐってみる~。
ヤバ~。楽し~