関数に渡される配列オプションのマルチツリー構造を説明する、読みやすく理解しやすいドキュメントを書くのに苦労しています。
配列構造の例を次に示します。
$arr = array(
'fields'=>array(
'title'=>array('name'=>'Document.title','format'=>'string','readonly'=>true)
)
);
上記の配列には多くのオプションがありますが、これはその構造を理解する関数のパラメーターとして使用されます。
function doSomething(array $arr) {...}
PHPDocで配列をどのように構造化するかを文書化したいのですが、正しいアプローチが何であるかわかりません。
これが私が今持っているものです。
/**
* Holds configuration settings for each field in a model.
* Defining the field options
*
* array['fields'] array Defines the feilds to be shown by scaffolding.
* array['fields'][fieldName] array Defines the options for a field, or just enables the field if array is not applied.
* array['fields'][fieldName]['name'] string Overrides the field name (default is the array key)
* array['fields'][fieldName]['model'] string (optional) Overrides the model if the field is a belongsTo assoicated value.
* array['fields'][fieldName]['width'] string Defines the width of the field for paginate views. Examples are "100px" or "auto"
* array['fields'][fieldName]['align'] string Alignment types for paginate views (left, right, center)
* array['fields'][fieldName]['format'] string Formatting options for paginate fields. Options include ('currency','Nice','niceShort','timeAgoInWords' or a valid Date() format)
* array['fields'][fieldName]['title'] string Changes the field name shown in views.
* array['fields'][fieldName]['desc'] string The description shown in edit/create views.
* array['fields'][fieldName]['readonly'] boolean True prevents users from changing the value in edit/create forms.
* array['fields'][fieldName]['type'] string Defines the input type used by the Form helper (example 'password')
* array['fields'][fieldName]['options'] array Defines a list of string options for drop down lists.
* array['fields'][fieldName]['editor'] boolean If set to True will show a WYSIWYG editor for this field.
* array['fields'][fieldName]['default'] string The default value for create forms.
*
* @param array $arr (See above)
* @return Object A new editor object.
**/
私の問題は、HTMLドキュメントが生成されるとき、非常にうまくフォーマットされていないことです。さらに、上記が配列構造を明確に説明しているのかどうかはわかりません。
別のアプローチはありますか?
いくつかの表を追加するだけで、見た目が良くなり、理解しやすくなります
/**
* Holds configuration settings for each field in a model.
* Defining the field options
*
* array['fields'] array Defines the fields to be shown by scaffolding.
* [fieldName] array Defines the options for a field, or just enables the field if array is not applied.
* ['name'] string Overrides the field name (default is the array key)
* ['model'] string (optional) Overrides the model if the field is a belongsTo associated value.
* ['width'] string Defines the width of the field for paginate views. Examples are "100px" or "auto"
* ['align'] string Alignment types for paginate views (left, right, center)
* ['format'] string Formatting options for paginate fields. Options include ('currency','Nice','niceShort','timeAgoInWords' or a valid Date() format)
* ['title'] string Changes the field name shown in views.
* ['desc'] string The description shown in edit/create views.
* ['readonly'] boolean True prevents users from changing the value in edit/create forms.
* ['type'] string Defines the input type used by the Form helper (example 'password')
* ['options'] array Defines a list of string options for drop down lists.
* ['editor'] boolean If set to True will show a WYSIWYG editor for this field.
* ['default'] string The default value for create forms.
*
* @param array $arr (See above)
* @return Object A new editor object.
**/
ネストされたリストのアプローチ:
<ul>
<li>
array['fields'] array Defines the fields to be shown by scaffolding.
<ul>
<li>
[fieldName] array Defines the options for a field, or just enables the field if array is not applied.
<ul>
<li> ['name'] <i><u>string</u></i> Overrides the field name (default is the array key) </li>
<li> ['model'] <i><u>string</u></i> (optional) Overrides the model if the field is a belongsTo associated value.</li>
<li> ['width'] <i><u>string</u></i> Defines the width of the field for paginate views. Examples are "100px" or "auto"</li>
<li> ['align'] <i><u>string</u></i> Alignment types for paginate views (left, right, center)</li>
<li> ['format'] <i><u>string</u></i> Formatting options for paginate fields. Options include ('currency','Nice','niceShort','timeAgoInWords' or a valid Date() format)</li>
<li> ['title'] <i><u>string</u></i> Changes the field name shown in views.</li>
<li> ['desc'] <i><u>string</u></i> The description shown in edit/create views.</li>
<li> ['readonly'] <i><u>boolean</u></i> True prevents users from changing the value in edit/create forms.</li>
<li> ['type'] <i><u>string</u></i> Defines the input type used by the Form helper (example 'password')</li>
<li> ['options'] <i><u>array</u></i> Defines a list of string options for drop down lists.</li>
<li> ['editor'] <i><u>boolean</u></i> If set to True will show a WYSIWYG editor for this field.</li>
<li> ['default'] <i><u>string</u></i> The default value for create forms.</li>
</ul>
</li>
</ul>
</li>
</ul>
結果:
あなたがそれを派手に見せたいなら、少しのCssでそれは驚異を作ります! xd
パーティーには少し遅すぎますが、これは私が代わりに行う方法です:
/**
* Class constructor.
*
* @param array $params Array containing the necessary params.
* $params = [
* 'hostname' => (string) DB hostname. Required.
* 'databaseName' => (string) DB name. Required.
* 'username' => (string) DB username. Required.
* 'password' => (string) DB password. Required.
* 'port' => (int) DB port. Default: 1433.
* 'sublevel' => [
* 'key' => (\stdClass) Value description.
* ]
* ]
*/
public function __construct(array $params){}
とてもきれいで、何を理解しやすいと思いますか$params
である必要があります。
phpstormのプラグイン を作成しました。これにより、次のようなキーを指定できます。
(基本的に@siannoneの形式のわずかに厳密なバージョン)
/**
* @param array $arr = [
* 'fields' => [ // Defines the feilds to be shown by scaffolding
* $anyKey => [
* 'name' => 'sale', // Overrides the field name (default is the array key)
* 'model' => 'customer', // (optional) Overrides the model if the field is a belongsTo associated value.
* 'width' => '100px', // Defines the width of the field for paginate views. Examples are "100px" or "auto"
* 'align' => 'center', // Alignment types for paginate views (left, right, center)
* 'format' => 'Nice', // Formatting options for paginate fields. Options include ('currency','Nice','niceShort','timeAgoInWords' or a valid Date() format)
* 'title' => 'Sale', // Changes the field name shown in views.
* 'desc' => 'A deal another person that results in money', // The description shown in edit/create views.
* 'readonly' => false, // True prevents users from changing the value in edit/create forms.
* 'type' => 'password', // Defines the input type used by the Form helper
* 'options' => ['option1', 'option2'], // Defines a list of string options for drop down lists.
* 'editor' => false, // If set to True will show a WYSIWYG editor for this field.
* 'default' => '', // The default value for create forms.
* ],
* ],
* ]
*/
public static function processForm($arr)
{
$fieldName = 'sale';
$arr['fields'][$fieldName][''];
}
@return
キーも指定できます:
/**
* @return array [
* 'success' => true,
* 'formObject' => new Form,
* 'errors' => [],
* ]
*/
public static function processForm($arr);
配列の代わりにオブジェクトを使用できますか?それは文書化を簡単にします。
class Field {
/**
* The name of the thing.
* @var string
*/
protected $name;
protected $model;
protected $width;
//...
public function getName() {...}
public function setName() {...}
//...
}
class FieldList implements SomeKindOfIterator {
/**
* Some fields.
* @var Field[]
*/
protected $fields = array();
/**
* ...
*/
public function Push(Field $field) {
$this->fields[] = $field;
}
//...
}
次に、クラスが必要な場所で型ヒントを使用できます。
/**
* Do something.
* @param FieldList $field_list The field.
*/
function doSomething(FieldList $field_list) {...}
オブジェクト表記のマークダウン構文 (MSON)の方が適切な場合があります。
例
/**
* @param array $config
* + app (string, required) - app directory name
* + view (string, required) - view directory name
* + type (enum[string]) - site type
* + pc - PC version
* + wap - mobile version
* + other - other, default value
* + table_prefix (string) - database table prefix
*/
私はこの方が好きです:
* @param array $doc
* 'type'=>Doc::MY_DOC_TYPE,
* 'created'=>$now,
* 'modified'=>$now
コードを初期化する場所から貼り付けるだけで、すばやく簡単にできます。
これはディレクティブではなく純粋に表示であり、ドキュメント内でスペースの書式を保持する必要があるため、文字の壁ではなくインデントで読みやすくしたいと思います:
* array['fields'] array Defines the feilds to be shown by scaffolding.
* [fieldName] array Defines the options for a field, or just enables
* the field if array is not applied.
* ['name'] string Overrides the field name (default is the
* array key)
* ['model'] string (optional) Overrides the model if the field is
* a belongsTo assoicated value.
* ['width'] string Defines the width of the field for paginate
* views.
* Examples are "100px" or "auto"
* ['align'] string Alignment types for paginate views (left,
* right, center)
* ['format'] string Formatting options for paginate fields.
* Options include 'currency', 'Nice',
* 'niceShort', 'timeAgoInWords' or a valid
* Date() format)
* ['title'] string Changes the field name shown in views.
* ['desc'] string The description shown in edit/create views.
* ['readonly'] boolean True prevents users from changing the
* value in edit/create forms.
* ['type'] string Defines the input type used by the Form helper
* (example 'password')
* ['options'] array Defines a list of string options for drop-
* down lists.
* ['editor'] boolean If set to True will show a WYSIWYG editor
* for this field.
* ['default'] string The default value for create forms.
実際のPHPインデント付きの配列定義を使用するとさらにきれいになりますが
PHPの配列は、実際には匿名構造体に似ています。
任意のデータ構造には多くのスキーマバリデータがありますが、残念ながらタイプヒンティングでは広くサポートされていません。おそらくいくつかの一般的なスキームにはプラグインがありますか?問題は、1つまたは少数の場所でのみ機能することです。 IDEに対して正常な動作をするかもしれませんが、静的解析を実行すると、すべてが地獄に落ちます。
可能であれば、プラグイン経由など、スキームをサポートしない他のツールが単純にそれを無視するように、物事を分離するように注意する必要があります。
PHPDocはどこでもサポートされる傾向がありますが、非常に限られています。
多くの提案がありますが、本当の良い基準はありません。ほとんどのソリューションは非標準で、広くサポートされていない、制限付きの部分的なハッキングまたは純粋に表面的な(ドキュメント)です。
特定の場所には特定の実装がありますが、PHP自体に広く普及した専用のものはありません。ただし、独自のスキーマをPHP 、名前にPHP。
フィールド構造体を個別に定義する必要があります。外部データ構造は、多次元配列としてではなく、擬似コード@key fields field[]
としてです。概念的に混乱を招くように、次のことを行うことができます。
@start struct custom
@key \stdClass *
@end struct
@start struct fields
@key string hostname
@key string databaseName
@key string password
@key int port=1433
@key custom|undefined sublevel
@end struct
@start struct connection
@key fields fields
@end struct
または、Cから盗み、言語を発明します...
struct connection {
struct fields {
string hostname;
string databaseName;
string password;
int port = 1433;
custom optional sublevel {
stdClass *;
};
};
};
構造体に基づくスキーマを作成して、フラットとネストの両方を許可できます。入れ子はデフォルトである必要があり、再利用のために必要なものとしてアクセスできるようにのみ定義する必要があります。
珍しいアプローチは、代わりにオブジェクトを使用することです。これは、配列アクセスなどのインターフェースの使用を伴う必要はありません。 PHPオブジェクトはプロパティの配列をラップします。配列をオブジェクトに実装(実装なしでプロパティのみ)してキャストすることができます。
代わりに連想配列($ array [$ key]対$ object-> {$ key})としてオブジェクトを使用する場合、少なくともIDEをだますダミーオブジェクトを作成できます。
final class PersonStruct {
/** @var int */
public $x;
/** @var int $y */
public int $z;
}
動作する場合と動作しない場合があるこれらの3つのオプションは、使用するツールによって異なります。
嘘をつくことができます...
/** @var PersonStruct $ps */
$ps = (object)['x' => 0, 'y' => 1, 'z' => 2];
/**
* @param PersonStruct $ps
* @return PersonStruct
*/
function f(object $ps):object {
return $ps;
}
/**
* @param PersonStruct $ps
* @return PersonStruct
*/
function f(stdClass $ps):stdClass {
return $ps;
}
これの問題は、配列をオブジェクトに変換することを意味することです。これには、パフォーマンスへの影響と、参照渡しによる値渡しによる変更の両方があります。どちらが速いかは議論の余地があります。オブジェクトはデフォルトで参照される利点があり、PHPとは異なり、オブジェクトを配列から分離するJSONでより良く機能しますが、理論的には配列はより高速になります。
オブジェクトは、オブジェクトのプロパティが単なるPHP配列(代わりに->{key}
を使用) [key]
)。他の奇妙なことの可能性があります。
パフォーマンスが本当に懸念される場合は、PHPをコンパイル済みの言語に変換できます。同じ方法で、インターフェイスを拡張してオブジェクトをコンパイル可能にすることができます。 with OOP and auto-completeしかし、ラップするプロパティを指定することでクラスをインライン化するのと同等のことを行うことができます。いくつかの追加ビットが必要です(インライン化するか、手続き型に変換するか、単一のプロパティをラップまたは複数に変換するなど)。
この概念は、ボクシングとボックス解除に似ています。 SAサポートとIDE(オートコンプリート、チェックなど)、アナライザー、ツールなどの広範なサポート)について本当に狂っている場合は、それが唯一の方法かもしれません。