Created attachment 107821 [details]
Test code for the mentioned issue

UPDATE:

/**
 * Function baz
 * @param string the class name
 * @return Test
 */
function baz($my_class){
    return new $my_class;
}

$t = baz('Test');
$t->... 

This time it correctly parsed the Class methods and properties. However, if it's going to be creating instances dinamycally I can't rely on the PHPDoc.
Please see: http://goo.gl/gBx0l


BTW, in this way doesn't works:

* @return $myclass
-> [ No suggestions ]

This is not easy to support and it's almost impossible to find the right type. What happen when you will have:


function baz($my_class){
    $my_class = $namespace . '\' . $my_class
    return new $my_class;
}

or something like this, where the name of class is composed through an algorithm, which is in the most cases? NetBeans can not predict the values of variables.

In the code you can always use @var tag helper like this:

<?php

class Test {
    public $status;
    public $is_on;

    function foo(){
        // do something
    }
}


function bar($name){
    return new $name;
}

$x=bar('Test');
/* @var $x Test */
$x->                              


The comment /* @var $x Test */ is saying that from this line the $x is threated as an instance of Test class. 

You can read more here http://blogs.sun.com/netbeansphp/entry/defining_a_variable_type_in

I can extend type resolving for case that you mentined, but I'm afraid that it will not work in the reality.

Hi Petr.

Glad you gave me that guideness and indeed it does what I expected from the test code.

I can apply that approach to new fresh code I'm going to write. 
However, since I'm implementing the aforementioned framework (I hope you had the chance to look at it), and across different methods and classes new instances are created this way it would be REALLY helpful to not just rely on the vdoc feature (even, as I said, it really does what's expected).

If not possible then I should start documenting the whole framework and I can't imagine a way to make it flexible.
I mean, when the steps from the variable instantiation are far away than just 1 function call, something like this:

$b->js('click')->univ()->dialogURL('Sample',$this->api->getDestinationURL('./subpage'), array('width'=>1000));

This will produce an HTML button with an action bound to the click event. (http://agiletoolkit.org/example/refresh1)


Method chaining is one of the greatest abilities of this framework and why I loved it almost instantly, but if is not possible for NB to find the declaration or suggest me methods/properties it will be hard (since I'm pretty new to it).

I hope you can do something about this for the next release. Again, it would be REALLY HELPFUL!

Thanks

PS: Sorry for reporting as a BUG. Now I know it's clearly an enhancement.

In the example like:

$button = $b->js('click')->univ()->dialogURL('Sample',$this->api->getDestinationURL('./subpage'),array('width'=>1000));

NetBeans should be able to recognized the type of $button if the return types are known for all methods in the chain. 

But this has also one performance impact. The finding return types of a method (if the return type is not defined through the php doc) require scanning the method body that can be slow in the case of long chain.

Hi Petr.

To introduce myself, I'm the lead contributor of Agile Toolkit. We have a stable branch of Agile Toolkit but are also working on development copy and are focusing on code overhaul. 

We are very interested in helping you out by structuring the code and comments in such a way to make NetBeans parse it easier. I would gladly accept any suggestions you have and make them into our development release.

The biggest issue with the structure and code hinting is - all objects are cerated through "add"method 

http://agiletoolkit.org/doc/learn/adding

The class name is passed as 1st argument, but I suppose for IDE it's difficult to link it to the return type. In general we can assume that add() returns "AbstractObject" descendant, but unfortunately properties added in that descendant can't be accessed. 

If it would be any other language, I would write:

class *Form form = this->add('Form');
form->[...]

but I do not know how to do that in PHP. We also discussed possibility of dropping add() method, and it would be a too fundamental change destroying a core strength of the framework.

Any suggestions on how to make a compliant code are highly welcome.

Being frank I still haven't tried the button example, however I'm writing a pretty simpler code:

//-- F O R M ---------------------------------------
    /* @var $f Form */
    $f->addField('line','first_name')->...[ No suggestions ];

In that way NB recognized the methods of $f, however isn't recognizing the upcoming, which could be "validateNotNull" and others, related to the field type being returned.

For instance:
$f->addField('line','email')
    ->validateNotNull()
    ->validateField('filter_var($this->get(), FILTER_VALIDATE_EMAIL)');


Of course I know this could have a huge performance impact and depending also on the size of the framework.
I believe that making optional (default OFF) the "deeper code parse - class eploring" would allow some people (like me, that really need that help from NB *AND* also have a very powerful box) to get the needed behavior.

What do you think?