どこに行ったの
トラフィックが少なく、「私と私の...素敵な猫」のスタイルの記事を含むWebサイトがあり、定期的に更新しています。 そして、もちろん、私はそれに何らかのCMSを固定しようとしました。 最初はWikiエンジンでしたが、それからブログになりました。 もちろん、トラフィックが少なく、ホスティングリソースが弱いため、サイトを100％静的に変換することを考えました。
そしてそれは始まった
適切なジェネレーターを見つけ、エンジンのデータベースのレコードをファイルに変換し、喜ぶことを望んでいました。 しかし、そこにありました。 Webgenは最初に手に入れたものですが、「ソースファイルにはいくつかのテキストブロック（たとえば、メインテキストとマージンテキスト）が含まれている可能性があります」というフレーズがすぐに消えました。 私はコンテンツとプレゼンテーションを分離することが重要でしたが、このアプローチは私には不向きでした。
「ない」
それから私は「市場に出ている」ほとんどすべてのものを試し、私にとって重要な「ない」のリストが形成され始めました。
ファイル名は、サイトの外観や拡張子に影響を与えてはなりません
多くのエンジンは特定のファイル名形式を必要とし、おそらくその70％が拡張機能を使用して簡易マークアップ言語（たとえば、.md-Markdown）を指定します。 ファイル名はこのデータの単なる識別子であり、あまり付けないでください。
同じ方法ですべてのメタデータを指定する方が便利であり、ファイルヘッダーはこれに適しています。 または、サイト構成ファイル。 たとえば、この段階で、美しいジェキルは倒れました。
このサイトでは、サーバーを表示する必要はありません
なぜ一般的な静的サイトなのですか？ 原則として、「/ top-level / dir / file.html」のようなリンクを作成する方がプログラミングが簡単ですが、これにより、たとえばフラッシュドライブからサイトを表示する可能性が排除されます。 また、プレビューのためにサーバーを起動する必要があります。 だから私は自分自身に関連するリンクを作成しました。
エンジンには、「メニュー」、「サイドバー」などの機能がありません。
サイトの構造は、ディレクトリとファイルのみです。 メニューの結論は、テンプレートエンジンの動作です。 もちろん、メニューを設定するための別の機能は、テンプレートの作成を容易にしますが、プロセスの柔軟性を低下させます。 その後、多くのエンジンがすぐに姿を消しました...
記事の作成は複雑ではありません。 まったくない
それはもっと簡単に見えるでしょう-テキストファイルを書きます。 最初はメタデータをYAML形式で設定するのが好きでしたが、母国語が英語である限り、これはすべて素晴らしいことです。 通常のCMSのインターフェースはRussifiedであるため、静的サイトのジェネレーターに切り替えると、次のように記述する必要があります。
title: date: 01-01-2012
結局のところ、それはいです。 一方、テンプレートエンジンの名前は統一されている方がよいため、私のジェネレーターでは、ローカライズされたフィールド名から内部フィールド名に変換しました。
簡素化されたテンプレートエンジンは必要ありません
かつて、私はTAL言語が本当に好きでした。 このような背景に対して、他のテンプレートエンジンは少し貧弱に見えましたが、最も重要なことには、TALはデザイナーにとって最も使いやすいものです。 テンプレートの開発プロセスでは、ブラウザで簡単に見ることができ、完成したテンプレートの「再活性化」には30分もかかりません。 TAL（PubTAL）を使用した静的サイトジェネレーターも見つけましたが、それは多くのブログであり、...
すべてのウェブサイトがブログではない
ブログの場合でも、「カレンダー」ナビゲーションはあまり便利ではありません（私の意見では）。 そのため、投稿を主に日付ごとに整理するエンジンについては考慮しませんでした。
コードやテキストに干渉する必要はありません
私の意見では、サイトのコードとソースコードを1つのディレクトリに保存するのは良くありません。 プログラムのインストールディレクトリがあり、すべてのプラグインがそこに移動し、それらの構成ファイルのみがサイトのディレクトリに残る必要があります。 しかし、何らかの理由で、このようなプロジェクトのすべての開発者がこの決定を下したわけではありません。 さらに、私は自分のエンジンで複数のサイトを立ち上げることを計画しましたが、実際には、プログラムのいくつかのインストールが私にとって面倒すぎることを監視しました。
ローカルの問題を解決するサイト固有のコードをサイトのディレクトリに追加する機能はありますが、プラグインのディレクトリが「プライベート」なタスクで乱雑にならないように後で追加しました。
CMS開発者はサイト構造を考えるべきではありません
プログラマが考えているサイトの構造が何であれ、ユーザーは別のものを望んでいます。 したがって、私の意見では、ディレクトリ構造のすべての機能（ソースコードと完成したサイトの両方）が、カスタマイズ可能、そして可能であれば任意になります。
プロセスで生成できることを事前に行う必要はありません
たとえば、カテゴリとタグは事前にペイントするのは不便です。同時に、ファイルヘッダー内のタグの単純なリストを使用してそれらを生成するために必要なすべての作業を行うことは難しくありません。
ユーザーのことを考える必要はありません
「ない」よりも「はい」の可能性が高いですが、それでも重要です。 たとえば、タグ「Cat」が一方の記事に割り当てられ、タグ「CAT」がもう一方の記事に割り当てられている場合、それらはもちろん同じタグの下にリストされますが、特定の記事のタグが表示されるときは、スペルを保持する必要があります。
どうした
試供品はなく、数十の発電機のいずれかを終了するか、耐えなければならないことが判明しました。 だから私はあなたの自転車を書くことは物事をそれほど複雑にしないだろうと思った。 ただたくさんの無料の夜を過ごしました...
最初はPHPで書き込もうとしました。Webでもっと勉強した方がいいと思ったからです（辞書で読みました）が、まったくうまくいきませんでした。 最初のバージョンはPearlに積まれてから、3番目のPythonに切り替えられました。 完全に動作可能な状態では、発電機は1年のうちのどこかでのみ流出しました。 現在、このジェネレーターでは、機能するWebサイトを開始しています。
PS
私が（おそらく）思いついたものの中で、タグを音訳するためのユーザールールについて説明します（簡単にするため、私は音訳を原始的な「ステミング」として使用します）。 つまり、タグ「game」と「games」をシステムによってまったく同じものとして受け入れられるように設定できれば、それは良い考えのようです。
PPS
ソースファイルの例を次に示します。
: : 2012/3/1 10:18 : , , id: 115 # "" , . , --- ... <a href="/+id:123"> id - </a>