Существует ли стандарт для документирования параметров GET / POST? - PullRequest
16 голосов
/ 23 января 2010

В проекте PHP, даже если логика фронт-контроллера используется для основного приложения, может быть много автономных сценариев, фрагментов ajax и т. Д.

Есть ли стандартизированный способ - либо PHPDoc, либо что-то еще - чтобы определить в первом блоке комментариев скрипта, какие параметры GET и / или POST скрипт примет / потребует и какого типа они являются?

Я обычно помогаю себе, просто добавляя @param s, как если бы файл был функцией, и @return объяснение того, что скрипт делает и возвращает, но, возможно, есть более специализированный способ, о котором я не знаю.

Ответы [ 3 ]

2 голосов
/ 01 февраля 2010

phpDocumentor не понравятся теги @ param и @ return в уровне файлов докблок ...

Если вы выберете отдельный файл для их документирования, согласно ответу Mr-sk , вы можете использовать @ link , чтобы указать там, но это не будет сразу видно на странице документации вашего файла ... это будет просто гиперссылка, по которой вам нужно будет перейти, чтобы просмотреть информацию. Если вы хотите, чтобы какое-либо содержимое этого файла было видно на странице документации для вашего файла сценария, вы можете использовать встроенный тег {@ example} , чтобы указать на него, или даже только определенные строки в нем, например, {@ example / path / to / file 3 5} , чтобы отображались только строки с третьей по пятую.

В этом сценарии я бы, вероятно, решил просто объяснить вещи в длинном описании докблока на уровне файлов, поскольку на самом деле нет прямого способа пометить ваши параметры так, чтобы phpDocumentor распознал их как элементы кода в любом случае. Если бы любой из параметров, которые я использовал в своих описаниях, действительно был документированным элементом кода, который происходит где-то еще в коде, я бы использовал встроенный тег {@ link} , чтобы указывать на этот элемент кода.

Например, предположим, что есть некоторые константы, определенные в другом файле кода, и собственная документация этих элементов генерируется, когда этот другой файл анализируется. Если мое длинное описание, которое я записываю в докблок на уровне файла файла, содержащего только сценарий (например, ваше), говорит об этих константах в качестве параметров, то мое предложение может быть следующим:

If $POST['foo'] is set, its value should always be either {@link BAR_CONST} or {@link BAZ_CONST}.

Ссылки:

2 голосов
/ 23 января 2010

Пекка,

Я бы хотел использовать WADL для документирования взаимодействия с вашим API. Он не отвечает непосредственно на ваш вопрос - потому что он не генерируется из документации по исходному коду, его XML и поддерживается отдельно.

Он отвечает прямо на это:

какие параметры GET и / или POST скрипт будет принимать / требовать и к какому типу они относятся

Вы можете разместить образцы полезных данных в документе вместе с параметрами URI, принятыми типами содержимого, кодами ошибок / ответами / полезными нагрузками. Я нахожу это очень ценным, и с помощью WADL кто-то может кодировать клиента под ваш API.

Для получения дополнительной информации: http://research.sun.com/techrep/2006/abstract-153.html и: http://en.wikipedia.org/wiki/Web_Application_Description_Language

1 голос
/ 11 мая 2016

Я бы использовал @uses или @see В настоящее время я использую @uses, потому что он читается лучше и имеет смысл

Ссылка: https://phpdoc.org/docs/latest/references/phpdoc/tags/uses.html

...