The API gives the code as:
public function up()
{
$this->addColumn('table_name', 'column_name', 'string', $options);
}
but there's no documentation for what can be included in the options array.
http://www.doctrine-project.org/Doctrine_Migration_Base/1_2#method_addcolumn
For people coming in: it looks like this is really defined from the Data Access Layer. Here is the list of options for columns from the DBAL docs: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html
The documentation is wrong. Looking in Doctrine/Migration/base.php, you can see the following function prototype:
/**
* Add a add column change.
*
* #param string $tableName Name of the table
* #param string $columnName Name of the column
* #param string $type Type of the column
* #param string $length Length of the column
* #param array $options Array of options for the column
* #return void
*/
public function addColumn($tableName, $columnName, $type, $length = null, array $options = array())
So to add the length, you give it as the 4th parameter. I'm ignoring the options for the moment.
Following the "browse code" link on the top, you can follow the code to $options['length'] in Doctrine_Migration_Base::column() and the second parameter in Doctrine_Migration_Base::_addChange(). Check out the source code from time to time, it gives you an overview :)
Related
What is the correct syntax to document an array of mixed strings and ints?
public function toArray(): array
{
return [
'string',
42,
];
}
Here are the options I've considered:
/**
* #return string|int[]
*/
But this seems to indicate it would either be a string or an int[]
/**
* #return string[]|int[]
*/
And this would seem to indicate either an array of strings or an array of ints.
You can use
#return (int|string)[]
More details on phpdoc
Have a look on this document
at the last last bottom of the page
specified containing multiple types, the Type definition informs the reader of the type of each array element. Each element can be of any of the given types.
#return (int|string)[]
Also have a look on return in case needed more details.
This question already has answers here:
Best way to document Array options in PHPDoc?
(9 answers)
Closed 1 year ago.
How can I specify an array index and sub-index type? Note: I will use it with PHPStorm.
Array example:
function name ($options) {
// $options['length'] => integer
// $options['more'] => array
// $options['more']['test1'] => boolean
// $options['more']['test2'] => boolean
}
Example (that not works):
/**
* #param array $options
* #var int $length
* #var array $more
* #var bool $test1
* #var bool $test2
*/
In general, PhpStorm only support simple syntax, just as Sam has stated, e.g.
/**
* #param string[] $options
*/
The code above described parameter which is array of strings.
Install Options completion plugin -- it supports new proposed syntax for hashes (describing array keys and its' types) in PHPDoc: https://github.com/phpDocumentor/fig-standards/blob/master/proposed/phpdoc.md#7-describing-hashes
This plugin will add code completion for array keys.
<?php
class Element {
/**
* Initializes this class with the given options.
*
* #param array $options {
* #var bool $required Whether this element is required
* #var string $label The display name for this element
* }
*/
public function __construct(array $options = array())
{
// some code here
}
}
new Element(['label' => 'Bob', '|' ]);
// | Ctrl+Space will show supported attributes
NOTE: Main purpose of this plugin is to offer array keys completion -- I'm not sure how well it supports type resolutions for each of array elements (in case if they are different like in your example).
It looks like, according to the docs, that it's only possible to define an array as a set of one specific type (instead of setting a type for each index):
/**
* #param string[] $options
*/
The better solution would probably be to make $options a class, so length and test1 could be properties with default values and pre-defined types.
I found this question that had been answered, but it didn't solve my problem:
Aptana Scriptdoc doesn't show up in Code Assist
Using the PHP equivalent of their example...
/**
* Gets the current foo
* #param {String} $fooId The unique identifier for the foo.
* #return {Object} Returns the current foo.
*/
public function getFoo($fooId) {
return $bar[$fooId];
}
However, the documenation provided looks like this (extra ending braces included):
getFoo($fooId)
Gets the current foo
#param String $fooId The unique identifier for the foo.
#return Object}
Resolved return types: Object}
Please let me know what I'm doing wrong.
Thanks!
The #return type should not be wrapped with curly brackets.
Your doc should look like this:
/**
* Gets the current foo
* #param String $fooId The unique identifier for the foo.
* #return Object Returns the current foo.
*/
public function getFoo($fooId) {
return $bar[$fooId];
}
The parsing of the return type follows the PHPDoc #return rules.
This also means you can have a mixed return type, which will give you code-assist suggestions from multiple types.
For example:
/**
* #return MyClass|PDO doc doc doc
*/
Cheers
When creating form elements with Zend (using Zend Studio for Eclipse), I'd like some auto completion or hints. Here's what I'm thinking. I'm sure these exist, but I don't know how to get them.
I type createElement and auto-completes gives me the signature createElement($type, $name). Great, I select it.
but when I try to set the $type I don't get any hints like DateTextBox or ValidationTextBox. Being new, I see how this can be useful. What do you do to remember all the options?
for the array of attributes like require, invalidMessage, I'd like to get a list of those to choose from, and/or auto-complete when I start typing one.
// Date field
$date = $this->createElement('DateTextBox', 'date',
array('require' => 'true', 'invalidMessage' => 'Invalid date format')
);
$date->setLabel('date')->setRequired(true);
You have few options to help yourself, without waiting for any plugin:
learn it and remember ;)
extend your phpDoc blocks with all available options:
Example (to be honest I don't know if Eclipse supports html in phpDoc or even any text after variable name in #param, but it works fine in Netbeans):
/**
* [...]
* #param string $type Can be: <ul><li>DateTextBox</li><li>ValidationTextBox</li></ul>
* #param string $name Whatever
* #param array|Zend_Config $options Array with following keys: <ul><li>require</li><li>invalidMessage</li></ul>
* #return Zend_Form_Element
*/
public function createElement($type, $name, $options = null)
extend Zend class and create your own methods to simplify your work
Example:
class My_Zend_Form_Element extends Zend_Form_Element
{
public function createDateTextBox($name, $options = null)
{
return $this->createElement('DateTextBox', $name, $options);
}
}
declare some well named constants and provide some hint in phpDoc
Example: (type ZFE_OPTIONS and IDE should show hint with some constants to use as array keys)
/**
* Can be true or false
*/
define('ZFE_OPTIONS_REQUIRE','require');
create your own helper classes with methods to produce valid options array
Example:
class ZFE_Options
{
protected $opts = array();
/**
* #param bool $req
* #return ZFE_Options
*/
public function setRequired($req){
$this->opts['require'] = (bool)$req;
return $this;
}
/**
* #param string $txt
* #return ZFE_Options
*/
public function setInvalidMessage($txt){
$this->opts['invalidMessage'] = (string)$txt;
return $this;
}
/**
* #return array
*/
public function toArray(){
return $this->opts;
}
}
$zfe_options = new ZFE_Options();
$opts = $zfe_options
->setRequired(true)
->setInvalidMessage('Please provide valid email address')
->toArray();
That's not possible. It's not how autocompletion works. The hints you get are taken directly from ZF's code documentation. Nothing more, nothing less. Everything you see as hints is taken directly from the DocBlock and method signature, e.g.
/**
* Create an element
*
* Acts as a factory for creating elements. Elements created with this
* method will not be attached to the form, but will contain element
* settings as specified in the form object (including plugin loader
* prefix paths, default decorators, etc.).
*
* #param string $type
* #param string $name
* #param array|Zend_Config $options
* #return Zend_Form_Element
*/
public function createElement($type, $name, $options = null)
Eclipse can tell you to insert a string or an array and it will know that the method returns a Zend_Form_Element, but it cannot tell you what these strings should be.
The only place where I know something like what you describe exists is for CSS files. For some reason, when I type in display: it will give me an autocomplete box with possible values for this declaration. If you want more sophisticated autocomplete like this, consider filing this as a feature request to Zend.
Given a function which behaves as either a mutator or accessor depending on the arguments passed to it, like this:
// in PHP, you can pass any number of arguments to a function...
function cache($cacheName) {
$arguments = func_get_args();
if (count($arguments) >= 2) { // two arguments passed. MUTATOR.
$value = $arguments[1]; // use the second as the value
$this->cache[$cacheName] = $value; // *change* the stored value
} else { // 1 argument passed, ACCESSOR
return $this->cache[$cacheName]; // *get* the stored value
}
}
cache('foo', 'bar'); // nothing returned
cache('foo') // 'bar' returned
How do you document this in PHPDoc or a similar automated documentation creator? I had originally just written it like this:
/**
* Blah blah blah, you can use this as both a mutator and an accessor:
* As an accessor:
* #param $cacheName name of the variable to GET
* #return string the value...
*
* As a mutator:
* #param $cacheName name of the variable to SET
* #param $value the value to set
* #return void
*/
However, when this is run through phpDoc, it complains because there are 2 return tags, and the first #param $cacheName description is overwritten by the second.
Is there a way around this?
as you found out, you cannot document 2 different signatures of a single function. what you can do, however - if you use phpDocumentor -, is to document optional function parameters and multiple possible return types:
/**
* Blah blah blah, you can use this as both an accessor and a mutator, e.g.
* <code>cache('name') // get cache value</code>
* and
* <code>cache('name', 'value') // set new cache value</code>.
*
* #param string $cacheName name of the variable to GET|SET
* #param string $value optional new value
*
* #return string|void value of $cacheName or, in case of mutator, void
*/
for clarity, i would also include the usage example.