I am using PHPDocuementer and I keep getting these messages for my classes:
Parsing /code/vendor/prodigyview/helium/app.class.php
No summary for class \prodigyview\helium\He2App
But when code is the following:
<?php
/**
* The main application for instantiaing the He2MVC Framework and bringing together the parts required for the system to work.
*
* The application is what is called with Helium is first initiliaed in the frontend controller. It will autoload the components,
* set the registry and then send the application into the router. The boostrap of the framework should be called sometime during
* this point.
*
* #package prodigyview\helium
*/
namespace prodigyview\helium;
class He2App extends \PVStaticInstance {
}
Am I missing something?
The one docblock you have should be moved down to just above the class line. Its current location is being interpreted as the file-level docblock rather than a class-level docblock.
After doing this, you might start seeing warnings about file-level docblock missing. Just add a new docblock at the same place you have the current example one. You could use an exact copy of the one you already have up there, since its content seems to fit for the file as well as the class.
Related
I am recently start working on Phalcon. It is very good framework. I am trying to understand the design pattern of this.
Suppose that i am working on Form module. There is a class named Text and i am using this as $text = new Text("field_name");, Text class in included from use Phalcon\Forms\Element\Text;. Now i checked this namespace directory and found the Text class but there are only a render function. Here it is-
namespace Phalcon\Forms\Element;
/**
* Phalcon\Forms\Element\Text
*
* Component INPUT[type=text] for forms
*/
class Text extends \Phalcon\Forms\Element
{
/**
* Renders the element widget
*
* #param array $attributes
* #return string
*/
public function render($attributes = null) {}
}
Nothing is here for create a form element so i checked the parent class of Text but also this is inherited by an interface and its only define the all fucntions which present in its parent interface.
There are no defication for create a form elemet. Then how it's works?
How it can produce the code for an form element?
I also find such things in another module also. Please explain, is this any design pattern in oops?
I also works in npm and also checked packages they also have same design pattern.
You just checked php stubs. Phalcon is framework working as php extension wrriten in zephir which is translated to C and then compiled as extension and you can't edit and check it source code so easy.
Here you have this class - https://github.com/phalcon/cphalcon/blob/master/phalcon/forms/element/text.zep
First i think you should learn and check docs what you are actually using before start using it.
I'm having issues using the Codeception autoloader to load some abstract test classes. The reason for the abstract class is to mimic the structure of classes that are used in the application to cut down on the amount of code needed to test the application thoroughly.
Lets say I have an abstract class for testing, let say "AbstractRepositoryTester" which is only used in the "repositories" test suite (I like to separate things out for organisational purposes).
Each and every repository that I test that implements a "RepositoryContract" will have a test that also extends the "AbstractRepositoryTester" with some overridden abstract methods.
Now when doing this, the abstract class won't be loaded during testing and has to be loaded manually in a bootstrap file. There is also another abstraction that extends the vanilla Codeception test class so that I can set a few variables (namely for laracasts/testdummy).
Both classes will fail to load with out manual entry in to the _boostrap file. To add to this, the suite specific bootstrap file fails to load files or seemingly execute at all so I am forced to place all bootstrap code for all suites in to the global _bootstrap file.
I also attempted to use Codeceptions autoloading class \Codeception\Util\Autoload:: with the "load" method but it doesn't seem to work.
Right now I'm using require_once in the global _bootstrap so finally to the question:
Is there a correct way of autoloading (or just loading) a class to be used as part of a test both globally and per suite?
Am I on the right track overall in abstracting my tests like this? TDD is new to me and I am trying to better my development workflow (with help from Laracasts).
I've searched every where for an answer to load the classes I need but usually all I'll find is PHPUnit specific answers which don't appear to work. I have also peered through the Codeception documentation which feels a bit sparse on the subject and the API docs don't explain the method call usage in the case of Autoload::load
Cheers,
- Everon.
You can do this for your whole test suit, or just individual components. For example, for Unit tests only, do the following:
Add bootstrap: my_bootstrap_file.php to tests/unit.suite.yml:
# Codeception Test Suite Configuration
#
# Suite for unit or integration tests.
actor: UnitTester
bootstrap: my_bootstrap_file.php
modules:
enabled:
- Asserts
- \Helper\Unit
Call my_bootstrap_file.php something sensible like just bootstrap.php
Create tests/unit/my_bootstrap_file.php
<?php
\Codeception\Util\Autoload::addNamespace('', 'src');
The directory structure should look like this:
<project root>
src/
tests/
unit/
my_bootstrap_file.php
unit.suite.yml
Replace unit in the instructions above with acceptance, functional, etc. to apply it to different single components.
The PhpDoc for \Codeception\Util\Autoload::addNamespace():
/**
* Adds a base directory for a namespace prefix.
*
* Example:
*
* ```php
* <?php
* // app\Codeception\UserHelper will be loaded from
* '/path/to/helpers/UserHelper.php'
*
* Autoload::addNamespace('app\Codeception', '/path/to/helpers');
*
* // LoginPage will be loaded from '/path/to/pageobjects/LoginPage.php'
* Autoload::addNamespace('', '/path/to/pageobjects');
*
* Autoload::addNamespace('app\Codeception', '/path/to/controllers');
* ?>
* ```
*
* #param string $prefix The namespace prefix.
* #param string $base_dir A base directory for class files in the namespace.
* #param bool $prepend If true, prepend the base directory to the stack instead
* of appending it; this causes it to be searched
* first rather than last.
* #return void
*/
public static function addNamespace($prefix, $base_dir, $prepend = false)
If you want this to apply to your whole test suite, not just Unit tests, use codeception.yml instead of tests/unit.suite.yml, and tests/my_bootstrap_file.php instead of tests/unit/my_bootstrap_file.php.
<project root>
src/
tests/
my_bootstrap_file.php
codeception.yml
I'm working on a project that uses the Lithium (http://li3.me/) framework and they document their classes like this:
class Controller extends \lithium\core\Object {
/**
* Contains an instance of the `Request` object with all the details of the HTTP request that
* was dispatched to the controller object. Any parameters captured in routing, such as
* controller or action name are accessible as properties of this object, i.e.
* `$this->request->controller` or `$this->request->action`.
*
* #see lithium\action\Request
* #var object
*/
public $request = null;
I've always used fully qualified class names in the #var and Eclipse seems to do a good job with that for generating content assist. However they seem to document class names using #see tags instead, and content assist is not available. Is there a way to configure PDT to use the information in the #see tag as a class name for the purposes of content assist?
It's not possible without own plugin. #see tag should be used for links only.
I am using a framework that allows adding new components to the framework's base class. Is there any way to document these new methods without changing the frameworks files so I can click through to the method in my IDE.
I highly recommend against trying to inject a subclass. If the framework instantiates the class you're extending directly, you'll need to find a way to get it to use your subclass instead.
NetBeans and PhpStorm (and probably many others) will combine elements from multiple definitions of the same class/interface. This allows you to add properties and methods to any existing class without modifying the original source.
/**
* Framework controller base class.
* Provides helpers via __call().
*/
class Framework_Controller { ... }
Now create a file in your code base that you never require containing the same class definition. Your IDE should still parse it and merge its elements with the class above:
if (false) { // Safety first!
/**
* ACME Co. controller base class.
*
* #method ACME_Model_User getUser Load user via authentication helper
*/
class Framework_Controller { /* nothing to add */ }
}
You can try using an interface and declaring the methods normally instead of with #method. That is what we did with Zend_View since it's already an interface. I haven't tried mixing class with interface to see if PhpStorm likes it.
It depends mainly on IDE you are using. I think you should extend base class and add there some new methods/properties with phpdoc comments. Of course changing framework's files is no solution as you already mentioned
You could extend the original class, redefine the function, with new doc, and call the parent function.
e.g.
class newClass extends originalClass
{
/**
* New PHPDoc
*/
function functionName($a)
{
return parent::functionName($a);
}
}
Try to use #see or inline #link directives.
I have a large code library for which I am trying to generate hierarchical documentation. The project does not use namespaces but uses #package instead.
I just tried generating docs as a test from the following file with phpDocumentor2:
<?php
/**
* This is a file
* #package JustAn\Example
**/
/**
* Something class
**/
class Something{
function try_this(){
}
}
Though according to the docs #package JustAn\Example should be the equivalent of namespace JustAn\Example, I found this not to be the case.
When I use namespaces the resulting documentation is like this:
When I use the #package notation the result looks like this (even though it recognizes the package notation - this is shown on the full details page of the class):
I am looking for a way to get the hierarchical result without having to rewrite the code to use 'real' namespaces.
The problem is that the default "clean" template does not support this feature. Other templates (like "responsive" for example) do. You can use the --template="responsive" flag to change the default template used.
I see that you have the package tag in the file docblock, but not the class docblock. If you add it to your class docblock, I think it should work.