どうにも理解不能な業務系Webアプリの４つの「お作法」

「みんな昔からこうしてるから」という理由で受け継がれているらしい業務系Webアプリの、個人的に不可解に思うお作法４点。
自分の現場だけかな？

右クリックを禁止する。

HTMLソースコードを見せない為らしい。

・・・本気で何か仕掛けようとするなら

• Wiresharkでパケットキャプチャ
• WinInetのデバッグ用DLL突っ込んでダンプ(これならSSLかかっても、復号化された後のデータがログに出てくる)
• 同じくWinInetをVBAから呼び出して、ExcelなりWordなりからVBA叩いて直接HTTPを喋らせる。
• ほか、直接HTTP喋るツール突っ込む。

はい、終了。

これの何がキツイかというと、プログラムが出力するHTMLを即座に確認できない事。ましてや業務系のアプリってかなりレイアウトがTABLEタグの嵐になってたりするので、どこか崩れると調べて直すのがすごい辛い。
FirefoxでHTML ValidatorなりFireBugなりWebDeveloperなり入れてりゃ楽なんだけど。そもそもFirefoxみたいな「外部アプリケーションのインストール」に申請とか審査が必要だったりするので、面倒くさいのでみんな興味を示さない。IEが入っててデフォルトで動くんだからそれでいいじゃん、みたいな。

「戻る」ボタン抑制

状態を保持するFWの場合とかは「戻る」を押してもまぁちょっと画面遷移がおかしくなるだけだけれど、そもそも「戻る」ボタンを押してもhisotry.back()走らないようにしてるケース。

・・・何を目的としているのかがイマイチ理解不明。
「戻る」ボタンを押されてback, back, ...とされたら何かプログラムが異常動作でもするのかな？
登録系とかならまだしも、普通の公開コンテンツでページングと一覧・詳細の見るだけページでこれをするのは・・・何故？

フレームとJavaScriptの嵐

一昔前のソースコードをメンテしてる現場で時々見かけます。まぁその時作ったのはそれで良いけど、直しもせずコピペで新規業務に入れ込むケースはちょっと・・・。
いえね、二重位はまだ良いんですが。三重・四重になってその上右クリック→ソース表示禁止となると・・・ほんと、HTMLがおかしくなった時、ページをローカルに保存してエディタで開いて・・・ってしなくちゃいけない。めんどくさい。
更に面倒くさいのは、例えばナビゲーションボタンを何故か別フレームに集約している場合。もう・・・JavaScriptが絡み合って・・・追い切れない・・・。hidden値とかでバリバリ渡してるし・・・。１つの画面にボタンが5つも6つもあるし・・・。ボタンそれぞれにJavaScriptがonClick()で割り当ててあって、それぞれでFormのactionとかに別のactionいれてsubmit()かけて・・・って。

業務アプリにこそ状態遷移とイベント駆動のフレームワークを使うべきだと思うのですよ。だって、入力画面で必要とする派生入力項目やアクションがコンシューマ向けと比べて格段に多いから。そうなると、普通にFORMとSUBMITボタンだけじゃ成り立たなくなって、JavaScriptが入り乱れるようになっちゃうんです。
イベント駆動系だと、Submitのvalueとかnameとかでイベントを指定する事で、自然に画面遷移を繋げていけると思うのですが。

ちなみに、一昔前ですと10MbpsのLANであったり、28kbpsとか57kbpsのアナログ回線経由だったりしたので。フレームで区切って、ヘッダーやサイドバーなどの無駄な読み込みを抑制するというのはそれなりに効果がありました。

入力チェックをJavaScript「だけ」で終わらせている。

ついついJavaScriptをOFFにしたくなるのですが、大抵そういう業務向けWebアプリは、OFFにしたらボタンやナビゲーションのリンクが動かなくなるという素敵な作りになってます。・・・ああ、だからJavaScriptだけでも良いってか。

というわけで、業務向けWebアプリの開発現場ではみんな手間取ってますね・・・。JavaScriptにしたって、ライブラリとかは使わずにベタで色々書いてます。IEだけで動けば良いみたいですので、それでも構わないというスタンス。