インラインフレーム、フレームのどちらも使用せず
全てのページ内に共通のメニュー表示を行いたい場合
各ページ毎に各々入力を行うしかないのでしょうか？
メニューの増減を行うたびに５０〜７０前後のファイルを
各々入力しなおすとなるとリンク処理、画像の更新削除と
かなり手間がかかってしまうと予想されるので
更新時に手間のかからない方法は無いかと思案しています。
フレームの利用を避けたい理由は、メニュー部分が大きくなる為
どうしても分割部分にスクロールバーが表示されてしまい
意図したデザイン、レイアウトにならない為です。
どなたかご教示頂けないでしょうか。
SSIを使う
レスありがとうございます。
“SSI”について勉強してみます。
>>1
が正攻法だと思いますが、サーバー負荷的には素直に
フレームを使ったほうが良いかと思います。
外部jsファイルでメニューを表示させる方法もありますが、
モノがメニューだけに、クライアントに左右される可能性の
有るjavascriptでは不安もあります。
まぁ「アクセス数が多い共有サーバーだ」などの理由が無け
ればSSIでもかまいませんが。
メニューも内容を厳選してカテゴリー分類をしっかり行えば
スクロールバーにデザインを壊されるケースも減ると思うし
見る側にも判りやすくなって吉かと思います。
<!-- #INCLUDE FILE="common.inc" -->
の形式は、IISでしか使えないでしたっけ？
サーバに依存せずに使えるんでしたら、common.incの部分に、共通のHTMLを書けば済むと思うのですが。
>>4
それがSSIだよん。
<!--#include file="hoge.txt" --> サーバのパスの場合
<!--#include virtual="hoge.txt" --> URIのパスの場合
SSIを使って処理してみました。
で、目からウロコの便利さでした。
が、サーバーによってはSSIの使用が不可だったりするみたいですね。
その場合はやっぱりフレームを使うしかないんですかね。
検索エンジンからくる人の事を考えても、フレームはなるべく使いたくないですね。
50〜70ページほどでも、Perl等のプログラムで処理すれば、書き換えの手間もさしてないでしょう。ページごとの構成がばらばらだと面倒ですが。
>Perl等のプログラムで処理すれば、書き換えの手間もさしてないでしょう。
てことはCGIってことですよね？
その辺は苦手な分野なんですがこの機会に取り組んでみます。
みなさん、レスありがとうございました。
PerlといえばCGI、ばかりではありませんよ。ローカルのテキストファイルの加工にも便利に使えます。
object...
それくらいのボリュームになると
PHPやASPを使うのが今風の解決策でしょうか。
SSIと比較した場合の負荷については分かりません。
>>11
それよりSSIでインクルードした方が処理は軽いと思いますが。 phpにしろaspにしろスクリプトを実行するわけですから。
>>12
訂正。
phpにしろaspにしろスクリプトを実行するわけですから。
↓
phpやaspならばスクリプトを実行しなくてはならないですから。
PHPをApacheのモジュール版で使用すると仮定すると
SSIと処理の流れが似ている為、頭ではどっちが速いのか悩みます。
(かといってベンチマークを取る気は起こりませんが)
SSI: 拡張子 .shtml のファイル
PHP: 拡張子 .php のファイル
等が呼ばれると
↓
SSI: mod_includeモジュール
PHP: libphp4モジュール等
がファイルをパース。
↓
SSI: <!--#include file="hoge.txt"-->
PHP: <?readfile('hoge.txt')?>
等が実行される。
msdn library みたく解決するのもありでしょうか？
毎回フレームを切るという
>>14
でも今現在SSIが使えるサーバー数とPHP(ASPは。。。)が使えるサーバー数を比較するとSSIの方が多いと思いますね。
モジュール版であればSSIのインクルードもしなのむしさんが提示なさったサンプルでもあまり代わりは無いかも(xreaの鯖でテストしてもいいですけど。)
ちょっとベンチマークを取ってみました。
ssi.shtml (SSIでインクルード)
ssi.php (PHP4 の readfile でインクルード)
環境は手元の
CPU : Athlon MP 1.2G x 2
メモリ : 512MB
OS : Kondara MNU/Linux 2.1
Apache-1.3.26 / PHP4.1.2
こんな感じ。
$ ab -c 10 -t 100 http://localhost/ssi.shtml
$ ab -c 10 -t 100 http://localhost/ssi.php
として ab コマンドで計測したところ、
SSI
Requests per second: 306.42 [#/sec] (mean)
PHP
Requests per second: 688.82 [#/sec] (mean)
これはびっくり。PHPの方が速いとは。
# いまいち信じられん・・・
>>17
読み込むファイルの内容(若しくはファイルサイズ)はなんでしょう。
>>18
読み込むファイル (SSI / PHP)は 7KBほどのテキストファイル。
読み込まれる(include される)ファイルは 200 byte ほどのテキストファイルで実験しました。
大きなファイルだとどうなるか、ということで読み込むファイルを 27KB の HTML
読み込まれるファイルを 3.5KB の HTML にしたところ、
SSI
Requests per second: 85.03 [#/sec] (mean)
PHP4
Requests per second: 424.97 [#/sec] (mean)
更に大差が。
しかし PHP3 で同様のベンチを取ってみると、
>>17 の条件では
Requests per second: 192.79 [#/sec] (mean)
今回の条件では
Requests per second: 59.80 [#/sec] (mean)
となりました。
速度的には PHP4 > SSI > PHP3 ということですかね。
# PHP4 は何らかのキャシュをしている気がする。
>$ ab -c 10 -t 100 http://localhost/ssi.shtml
>$ ab -c 10 -t 100 http://localhost/ssi.php
自分もやってみましたが
shtmlの方は
Document Length、Total transferred、HTML transferred
を見る限りインクルード分を含まないで
呼ばれているみたいです。
（ベンチで呼ぶとSSIが効かない？）
ついでにPHP4の
includeとrequireでインクルード
する方法も試しましたが
<?readfile('hoge.txt')?>
の方が10%ほど速いです。
環境：cobalt raq4 (スペックは忘れた) PHP4.1.2 。
PHP3、PHP4はパーサの動作がだいぶ異なるらしいです。
SSIのベンチマークがまともに動いたんで
結果を書いておきます。
自分の環境では
SSI: <!--#include file="hoge.txt"-->
PHP4: <?readfile('hoge.txt')?>
は微妙にSSIが速いような雰囲気でしたが
ほぼ互角でした。
（読み込み側、読み込まれ側のファイルサイズの増減も試しました）
ふじさんのと比べるとかなり虚弱なマシンなのでその辺の差でしょうか。
# php.iniの設定の違いとかでも差が出そう。