I am developing a TYPO3 Extbase extension with PhpStorm. I am getting hundreds of notifications saying that Field x could not be found e.g. Field 'request' not found in DownloadController.
The official documentation only covers NetBeans and eclipse.
How does it work in PhpStorm?
Add TYPO3 Sources
Open your Project Tree (ALT-1)
At the end you find "External Libraries" -> RightClick -> Configure PHP include Paths -> add your TYPO3 source path
Set the right php version there as well
PHP Docs Comments
Be sure to use the right php annotation headers for every function - PHPStorm resolves them for the parameter info, and ExtBase uses them as well.
Example from the TYPO3 Core:
/**
* Returns the absolute filename of a relative reference, resolves the "EXT:" prefix
* (way of referring to files inside extensions) and checks that the file is inside
* the PATH_site of the TYPO3 installation and implies a check with
* \TYPO3\CMS\Core\Utility\GeneralUtility::validPathStr().
*
* #param string $filename The input filename/filepath to evaluate
* #param bool $onlyRelative If $onlyRelative is set (which it is by default), then only return values relative to the current PATH_site is accepted.
* #param bool $relToTYPO3_mainDir If $relToTYPO3_mainDir is set, then relative paths are relative to PATH_typo3 constant - otherwise (default) they are relative to PATH_site
* #return string Returns the absolute filename of $filename if valid, otherwise blank string.
*/
public static function getFileAbsFileName($filename, $onlyRelative = true, $relToTYPO3_mainDir = false)
{
...
}
Related
I am a bit baffled because some files in Linux kernel (notably include/linux/list.h) and all files is ccan have documentation comments resembling Doxygen ones (i.e.: enclosed in `/** ... */), but semantically different and Doxygen (at least with pretty standard options) chokes on them.
Typical example is (linux list.h):
/**
* INIT_LIST_HEAD - Initialize a list_head structure
* #list: list_head structure to be initialized.
*
* Initializes the list_head to point to itself. If it is a list header,
* the result is an empty list.
*/
static inline void INIT_LIST_HEAD(struct list_head *list)
{
WRITE_ONCE(list->next, list);
list->prev = list;
}
where I (and also Doxygen, I suspect) would have expected something like:
/**
* INIT_LIST_HEAD - Initialize a list_head structure
*
* Initializes the list_head to point to itself. If it is a list header,
* the result is an empty list.
*
* #param list list_head structure to be initialized.
*/
static inline void INIT_LIST_HEAD(struct list_head *list)
{
WRITE_ONCE(list->next, list);
list->prev = list;
}
Is this kind of documentation supposed to be digested by some other tool or am I simply missing some obscure (to me) parameter/configuration?
UPDATE:
I am aware (as #albert commented) that order is unimportant; what I find disconcerting is usage of #variable_name: doc string instead of #param variable_name doc string.
Trying to use Doxygen without specific care results in:
list.h:195: warning: Found unknown command '#list'
I could find no Doxyfile in either project and that's one reason why I suspect they're using some other tool, but I cannot divine what and how they're using it.
I will try to contact ccan maintainer directly.
Because the famous extension webkitpdf isn't maintained anymore, I try my very best to get this working under TYPO3 9.5.
My patched version https://github.com/EnzephaloN/typo3-extension-webkitpdf worked fine til 8.7, but now I get an error in Classes/Utility/CacheDatabaseBackend.php::set
/**
* Saves data in a cache file.
*
* #param string $entryIdentifier An identifier for this specific cache entry
* #param string $data The data to be stored
* #param array $tags Tags to associate with this cache entry
* #param integer $lifetime Lifetime of this cache entry in seconds. If NULL is specified, the default lifetime is used. "0" means unlimited liftime.
* #return void
*/
public function set($entryIdentifier, $data, array $tags = array(), $lifetime = NULL) {
if ($this->maximumNumberOfEntries > 0 && !$this->has($entryIdentifier)) {
$this->removeOldEntriesIfRequired();
}
parent::set($entryIdentifier, $data, $tags, $lifetime);
}
The parent::set($entryIdentifier, $data, $tags, $lifetime); results an Cannot call abstract method TYPO3\CMS\Core\Cache\Backend\BackendInterface::set() error.
Anyone an idea how to adjust this method to TYPO3 9.5??
Tried to extend from \TYPO3\CMS\Core\Cache\Backend\Typo3DatabaseBackend which caused a lot of trouble with different errors in backend.
For now I disabled calling parent::set(... - so it works without cache, but without errors.
In the BackendInterface the function set is defined like this:
public function set($entryIdentifier, $data, array $tags = [], $lifetime = null);
Nevertheless it never has a concrete function in class AbstractBackend in TYPO3 version 9. Probably in Version 8 that's different and the reason that it still worked.
So you've to define the function in your own class and it has to satisfy the requirements predefined in the BackendInterface like shown above.
To get an idea what the function is doing look in TYPO3 7 or 8. Even if you've to adjust it perhaps that might be useful.
EDIT:
In general to keep the call with parent::set(...); in your own function you still had to create another class. This is probably not required if you don't need the functionality additionally in another place.
In general you can just search in older versions what the function did there and integrate that functionality in your existing function set(...).
I have a javascript library for communicating with server APIS, written in modern ECMAScript.
It is fully documented with JSDoc comments:
/**
* #class - TODOS API Client class
*/
class todosApi {
/**
* Gets Todos, given the parameters
* #param {number} personId
* #param {number} [year]
* #param {number} [month]
* #param {number} [todoTypeId]
* #returns {Object} - api response object, data will be array of todos
*/
fetchTodos = async (....
}
When using this API in the unit tests in this project, in Visual Studio code, I have excellent intellisense from these comments, and it's a beautiful thing.
However, this library is used by/referenced in a separate react application created with create-react-app. When I run this through babel to transpile into a format that is consumable by my create-react-app app, it ends up like this:
/**
* #class - TODOS API Client class
*/
class todosApi {
_defineProperty(this, "fetchTodos", async (personId, eventYear, eventMonth, todoTypeId) => {
}
And I lose my intellisense for fetchTodos, and actually the class itself because of how it is exported in and index.js file. babel does have the option to include comments by default, however the class gets a little mangled in transpiling and loses some comments.
Is there any way to transpile and still preserve this intellisense for VS Code?
Use tsd-jsdoc to create a types.d.ts file.
In your package.json add a script to run ...
jsdoc -r src -t node_modules/tsd-jsdoc/dist -d lib
And set types to lib/types.d.js.
Include that script as part of prepublishOnly so it runs before every npm publish.
I browse and select new values at C build - Settings - Binary Parsers via
Binary Parser Options as a command.
But these selected values are can not be saved.
At the BinaryParsTab there is a comment. So these BinaryParserPages are can
not be saved at the moment as well ...
/**
* #noextend This class is not intended to be subclassed by clients.
*/
public class BinaryParsTab extends AbstractCPropertyTab {
/* Settings from binary parser pages are NOT saved by prior CDT version.
* So existing binary parsers _always_ use default values.
* Moreover, obsolete interface is used while attempting to save.
*
* We have to affect both parsers and pages
* to teach them to save data really.
*
* It will be done in next versions. Currently pages are disabled.
*/
I'm trying to document a Javascript file with JSDoc(3) like so:
/** 1 if gnome-bluetooth is available, 0 otherwise
* #type {boolean}
* #const
*/
const HAVE_BLUETOOTH = #HAVE_BLUETOOTH#;
Now the file (called config.js.in) is not on its own valid Javascript; the file gets run through a Makefile which substitutes an appropriate value for #HAVE_BLUETOOTH#.
When I try to run JSdoc on this, it (understandably) balks because of the syntax error in the file.
Is there some way to tell JSDoc to ignore all code in this file but simply take into account the annotations? (I might have to add #name tags to each doclet to completely separate the documentation from the code; that's fine).
Something like:
/** 1 if gnome-bluetooth is available, 0 otherwise
* #name HAVE_BLUETOOTH
* #type {boolean}
* #const
*/
/** #ignore */ // somehow ignore from here onwards
const HAVE_BLUETOOTH = #HAVE_BLUETOOTH#;
/** !#ignore */ // somehow don't ignore from here onwards (although I'd be happy
// to ignore the entire file)
I'd prefer not to modify the code part of the file, if possible (I'm adding documentation to an existing project). For example, I could probably get around it with
const HAVE_BLUETOOTH = parseInt('#HAVE_BLUETOOTH#', 10);
which would make the file have valid JS syntax again so that the parser doesn't complain, but this also means I'm modifying the code of the original file which I want to avoid (I prefer to just add documentation).
cheers
My case is similar because I use JSDoc to comment my .less and .css file. When I running JSDoc on set of file, I have the same issue.
So, I resolve my problem (with JSDoc 3.3.3) with the commentsOnly JSDoc plugin
https://github.com/jsdoc3/jsdoc/blob/master/plugins/commentsOnly.js
I have create this config.json:
{
"source": {
"includePattern": ".+\\.(css|less)?$"
},
"plugins": [
"plugin/commentsOnly"
]
}
with the commentsOnly.js file into a plugin/ directory (consider plugin/ and config.json are in same folder) and in this folder I execute the following CLI command:
jsdoc -c ./config.json ./assets/stylesheets/common.less
And it's work ! There are no reason this do not work with your files.
Hope I help you ;)