TControl.findControl method should find backward with Parent and Page keywords

[GoogleCodeExporter]

As it is possible to do with events handlers (e.g. OnClick="Page.doClick"). I 
think it should be possible to use "Parent" and "Page" keywords in properties 
that require a control id to get controls backward in the hierarchy.

Use case example :
.page file :
<com:MyNamingPanel ID="Pnl1">
    Txt 1 : <com:TTextbox ID="Txt1" />
</com:MyNamingPanel>
<com:MyNamingPanel ID="Pnl2">
    Txt 2 : <com:TTextbox ID="Txt2" />
    <com:TCompareValidator
        ControlToValidate="Txt2"
        ControlToCompare="Parent.Pnl1.Txt1"
        ErrorMessage="Error"
        Operator="Equal"
        DataType="String" />
        <!--- Another way (but less useful) : ControlToCompare="Page.TContentIdIfAny.TFormIdIfAny.Pnl1.Txt1" --->
</com:MyNamingPanel>
<com:TButton Text="Confirm" OnClick="click" />

MyNamingPanel.php file :
class MyNamingPanel extends TPanel implements INamingContainer
{
    //...
}

What is the expected output? What do you see instead?
Currently, if "Parent" or "Page" is used, findControl returns null. It should 
return the appropriate control in the hierarchy. 

However, I'm wondering if "Parent" should be the parent of the naming container 
or the parent of the control. ControlToValidate="Txt2" refer the the control id 
inside the naming container of the validator. So 
ControlToCompare="Parent.Pnl1.Txt1" should find the control Pnl1.Txt1 inside 
the parent of the naming container of the validator. But, "Parent" in events 
handlers refer to the parent of the control if I'm not mistaken.

What version of the product are you using? On what operating system?
3.1.10

Please provide any additional information below.

Here's a dirty solution :
public function findControl($id)
{
    $id=strtr($id,'.',self::ID_SEPARATOR);
    $container=($this instanceof INamingContainer)?$this:$this->getNamingContainer();
    if(!$container)
        return null;
    if($container->getHasControls() && !isset($container->_rf[self::RF_NAMED_CONTROLS]))
    {
        $container->_rf[self::RF_NAMED_CONTROLS]=array();
        $container->fillNameTable($container,$container->_rf[self::RF_CONTROLS]);
    }
    if(($pos=strpos($id,self::ID_SEPARATOR))===false)
    {
        if(!$container->getHasControls())
            return null;
        else
            return isset($container->_rf[self::RF_NAMED_CONTROLS][$id])?$container->_rf[self::RF_NAMED_CONTROLS][$id]:null;
    }
    else
    {
        $cid=substr($id,0,$pos);
        $sid=substr($id,$pos+1);
        if(strtolower($cid) == 'page')
        {
            $page = $this->getPage();
            return $page===null?null:$page->findControl($sid);
        }   
        else if(strtolower($cid) == 'parent')
        {
            $parent = $container->getParent();
            return $parent===null?null:$parent->findControl($sid);
        }
        else if($container->getHasControls() && isset($container->_rf[self::RF_NAMED_CONTROLS][$cid]))
            return $container->_rf[self::RF_NAMED_CONTROLS][$cid]->findControl($sid);
        else
            return null;
    }
}

Original issue reported on code.google.com by patricel...@gmail.com on 17 Nov 2011 at 7:20

[GoogleCodeExporter]

Prado is using TComponent::getSubProperty() calls on the current naming 
container where references to any controls (include those referrable with 
"Parent" or "Page") are needed and/or allowed. TControl::findControl() is just 
fine as it is (ie. finding only subcontrols), because not every property that 
references controls through their ids should be allowed to reference controls 
outside of the current container. 

Original comment by google...@pcforum.hu on 2 Mar 2012 at 3:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the anwser.

Why it shouldn't be allowed to reference controls outside of the current 
container for properties like ControlToValidate and ControlToCompare?

Original comment by patricel...@gmail.com on 2 Mar 2012 at 3:59

[GoogleCodeExporter]

I didn't say it should be allowed - just that there's already a method to 
resolve both Parent- and Page-relative references, if and where needed.

On the other side references outside of the current container cause issues with 
caching and can't be used reliable. That's the primary reason why references to 
Parent and Page aren't allowed in most properties that references other 
controls or their properties through IDs.

Original comment by google...@pcforum.hu on 5 Mar 2012 at 12:47

[GoogleCodeExporter]

Original comment by ctrlal...@gmail.com on 25 Jun 2012 at 1:56

• Added labels: Milestone-3.2.1
• Removed labels: Milestone-3.2a

[GoogleCodeExporter]

Original comment by ctrlal...@gmail.com on 21 Jan 2013 at 7:03

• Added labels: Milestone-3.2.2
• Removed labels: Milestone-3.2.1

[GoogleCodeExporter]

Original comment by ctrlal...@gmail.com on 24 Jul 2013 at 1:46

• Added labels: Milestone-3.2.3
• Removed labels: Milestone-3.2.2

[GoogleCodeExporter]

Moved to github: https://github.com/pradosoft/prado/issues

Original comment by ctrlal...@gmail.com on 1 Oct 2013 at 10:14

• Changed state: WontFix