私はurls.pyに、データベース内の適切なページが見つかると単純なビューを読み込むキャッチオールとして機能するエントリを持っています。このアプローチの問題は、URLソルバーが決して失敗しないということです。つまり、APPEND_SLASH機能は必要ではありません。DjangoキャッチオールURLを壊すことなくAPPEND_SLASH
静的ページURLに接頭辞を追加してキャッチオールであることを止める必要はありません。私は、urls.pyのエントリではなく404フックを使用するフラットページについて知っていますし、使用することを避けることを望んでいましたが、この問題は、まさにこの問題がユーザーが使用する理由のようなものかもしれません。
この問題を回避するにはどうしたらいいですか？または、私はただフラットページを与えて使用する必要がありますか？
キャッチオールURLパターンの末尾にスラッシュがあり、パターンがURLconfの最後であることを確認します。 catch-allパターンがスラッシュで終わっていない場合、ミドルウェアがスラッシュを追加しようとする前に、迷子のURLに一致します。
たとえば、最後のパターンとしてr'^.*'の代わりにr'^.*/$'を使用します。
同じことを行うには、名前付き引数としてビューにURLを渡します。r'^(?P<url>.*)/$'を使用します。
の静的なページが静的なページのように見える場合は、というステートメントを使用してください。静的なページは静的ではないようですので、urls.pyを使用してリンクを渡すかDBからのページをディレクトリに配置し、そのディレクトリを静的ファイルを提供するディレクトリとして設定する
まあ、厳密に静的ではありません。実際、彼らは実際には非常に単純なテンプレートでマークダウンとして解析されるので、htmlファイルとして扱うことはできません。だからええ、静的な誤解を招いている...大丈夫です。その説明を削除するために質問を編集しました。私が手動でエントリを追加するだけでなく、ソースファイルに触れることなくページを作成できるCMSのように機能させたいからです。 – nedned
私はあなたの答えを受け入れるだろう。私はこの同じ質問に対処していますが、私はもう一度それを聞くことはできません。私が与えることができるのはアップコートです。ブリリアント。 –
私はこのプロジェクトを完了したので、これをテストすることはできません。しかし、それは理にかなっており、ベンのフィードバックは励みになるので、私はそれを受け入れるだけです。 – nedned
唯一の欠点は、末尾のスラッシュのないURLに対してキャッチオールがなくなることです。 –