web-dev-qa-db-ja.com

カスタムコンポーネントの適切なフォルダー構造

新しいプロジェクトでjoomlatools joomla-console を使用しようとしています。ただし、ディレクトリ構造のため、symlink機能を使用できません。

過去には、常にシンプルなコンポーネントを構築してきました

administrator/
    controllers
    models
    views
    etc
site
    controllers
    models
    views
    etc

構造、およびそれをZip /インストールすると正常に動作します。

Joomlatoolsはあなたが使うべきだと言います

administrator/
  components/
    mycomponent/  
      controllers
      models
      views
      etc
site/
  components/
    mycomponent/
      controllers
      models
      views
      etc

構造。

何を使っていますか？どちらが「正しい」ですか？

component
6
user101289

コードを構造化する正しい方法や間違った方法はありませんが、より良い方法は確かにあります。

なぜ

Joomlatoolsで使用する構造は、標準化された開発者フレンドリーな構造を持つ必要性から生じています。車輪を再発明したくないので、最も論理的な選択はJoomlaの構造を使用することです。

Symlinkerは、GitリポジトリからJoomlaインストールにコードをシンボリックリンクする開発者向けに構築されています。私たちはこれをすべてのJoomlaコンポーネント開発に使用します。コードの同期を保ち、Gitリポジトリで直接作業しながらブランチを変更できるようにします。

Rsyncの問題は、コードの同期を保つには、rsyncが変更をコピーする必要があるため、変更が行われるたびに手動で再同期する必要があることです。これは開発時にはあまり役に立ちません。

利点

この構造を使用すると、次の利点があります。

  • Joomla Console の一部であるシンボリックリンカーを使用すると、ローカルのGitリポジトリからJoomlaインストールにコードを簡単にシンボリックリンクして、自動的に同期を保つことができます。

  • 複雑なパッケージで作業できます。 Joomlatools拡張機能には、コンポーネントだけでなく、モジュール、プラグイン、ライブラリなども含まれています。ユーザーがすべてを個別にインストールする必要がないように、これらすべてを1つのパッケージの一部にする必要があります。

    管理者/
コンポーネント/
 com_foo/
コントローラー
モデル
ビュー
モジュール/
 mod_bar 
 site /
 components /
 com_foo/
 controllers 
 models 
 views 
 modules/
 mod_bar 
 plugins /
 foo /
 bar /

Joomlatoolsの例Todoコンポーネント で見つけることができるこの構造の素晴らしい例。これはJoomlaの構造に準拠しており、ご覧のとおり、モジュールやプラグインなどが含まれています。

独自のシンボリックを作成する

最後に、Joomla Consoleを使用してrsyncを使用する場合、または好みの構造に従う独自のシンボリックソリューションを作成する場合は、コンソールプラグインの作成を検討できます。

コンソールの1.3バージョンのリリース を使用して、独自のプラグインを作成し、Packagistを使用してそれらを配布し、$ joomla plugin:installを使用してそれらをインストールできます。

幸せなコーディング！

4
Johan Janssens

構造に誤りはありません。Joomlaの良い点は、強制されないことです。インストール可能なアーカイブ内で構造化されるという点で最初のものが、標準に最も近いと言えます。一部の開発者はすべてを1つのディレクトリに置くことを好み、他の開発者は2-3個のよく分割されたフォルダを好みます。すべてが「機能する」ため、一部のファイルにはすべてのファイル用のフォルダーが含まれる場合もあります。個人的にはjoomlatoolsの経験はありませんが、その構造がインストールアーカイブ用である場合、どちらかといえば「過剰」に見え、2つのフォルダレベルの本当の理由はありません。

この次の部分は質問に直接関連していません

また、symlinkについては、実際に機能することはないと思います。ファイルが別のファイルを参照している場合、「実際の」ファイルに基づいてファイルを探します（つまり、root/installable/file.phpがroot/joomlaに移動している場合） /file.php root/installableにいることを前提としています）。それを回避する方法はあるかもしれませんが、潜在的な問題があまりない、rsyncというより良い代替案を見つけました。もちろんコマンドラインが必要ですが、sshアクセスが制限されていても、共有ホストでこれを実行しています。

#!/bin/bash

# sync
rsync -r /home/joomla/components/com_component/administrator/* /home/joomla/public_html/administrator/components/com_component/
rsync -r /home/joomla/components/com_component/site/* /home/joomla/public_html/components/com_component/
rsync -r /home/joomla/components/com_component/administrator/language/* /home/joomla/public_html/administrator/language/

少し理解しましたが、どのフォルダー構造でもファイルを適切なフォルダーにマップできることがわかります。データベースレコードを取得するために一度インストールするだけで済みます（変更した場合も同じです）。 CPを使用することもできるかもしれませんが、これは私にとってはうまくいったので、変更する理由はありませんでした（サーバー間で機能することができます）。

これは、更新を行うたびに実行する必要がありますが、こつをつかんだら難しくはありません。逆に行うこともできます。代わりに、コンポーネントの開発サイトで直接編集します（この場合も、回避策があるかもしれませんが、まだまだ作業していません）。

2
Jordan Ramstad

それは実際にはすべて個人の好みとマニフェストファイルで指定するものに依存しています。

マニフェストファイル（ZoomでJoomlaにファイル構造を伝える場所）を参照してください https://docs.joomla.org/Manifest_files

拡張機能固有のPhingビルドファイルを使用してプロジェクトをセットアップする場合、Zipが自動的にビルドされるため、一度設定すると二度と気になりません。 https://github.com/akeeba/buildfiles/blob/master/phing/README.md

0
Walt Sorensen