それで、Laravelに着きました。 管理パネルをすばやく作成し、フロントエンドにより多くの時間を費やすのに役立つパッケージを紹介します。
あなたは、私の「自転車」で、私がすべてを見るためにそれを公開した理由を尋ねますか？ 私にとって、これらは彼のいくつかの強みです。
ゼロ 、それは実際のプロジェクトで私を助けます。 おそらくそれは他の誰かを助けるでしょう、そしてこれはすでにすべてが無駄にされていないことを意味します。
まず 、構成ファイル。
私は設定にうんざりしています。これは魔法のように作成された配列で、特定の名前のキーとこれらのキーのテキスト値があります。 IDEからは、構成からの特定のキーが具体的に処理され、それが何をするのが簡単なタスクであるかをプロジェクトコード内で見つけるための、自動的な置換または誤って指定された値の強調表示はありません。 さらに、ここのパッケージコードは弱いヘルパーであり、ドキュメントはあなたの唯一の友達です。
したがって、配列形式の設定（php配列、yamlファイル、それは問題ではありません）を拒否し、phpコードの形式で設定を行いました。 以下は、管理パネルで使用するデモアプリケーションのカントリーモデルの説明の簡単な例です。
Admin::model('\Country')->title('Countries')->with('contacts')->columns(function () { Column::string('title', 'Title'); Column::count('contacts', 'Contacts')->append(Column::filter('country_id')->model('\Contact')); })->form(function () { FormItem::text('title', 'Title'); });
あなたのことは知りませんが、実際にはすべての同じ情報が含まれていますが、キーのある配列よりも読む方がはるかに便利なようです。
このアプローチのいくつかの利点：
- IDEはこのコードの実行コンテキストを認識し、どのタイプの列またはフォーム要素が存在し、特定の要素がどのような追加パラメーターを受け取るかを通知できます。
- 「キー」の名前にタイプミスがあると、アレイの構成では提供できないエラーが自動的に発生します。
- あまりにも多くの情報を含む配列を解析するのは楽しい作業ではありません。 すぐに、それは単に存在しません。その結果、コードはきれいになります。
第二に 、拡張性。
後でモデルで使用される独自の列タイプとフォーム要素を登録できます。 したがって、作成した機能だけに限定されません。
特定のメニュー項目を処理するために独自のコントローラーを登録することもできます-ここでは、すでに無制限です。
第三に 、管理パネルを作成するために必要な作業量。
メニューを作成し、管理パネルを作成する必要がある各モデルの説明を作成する必要があります。 そしてそれだけです。
このパッケージは、多くの相互接続が弱いモデルを持つ主に小さなプロジェクトで使用するために作成しました。 原則として、彼らの主な目標は、デザインに従ってフロントエンドでデータを表示することであり、顧客のためにどのような管理パネルが存在するかは、それが主な目標-サイトのコンテンツの管理-を満たすだけであれば、それほど重要ではありません。
GitHubソース | プロジェクトのドキュメント | デモアプリケーション