I did some minor work on this tonight and I have QTextBoxes working a lot better, and added in basic support for QLinkButtons. I also posted a .nbm, which you can find in the downloads section on the Google code website http://code.google.com/p/qcodo-netbeans-tools/. You can install it by going to Tools->Plugins and clicking on the 'Downloads' tab. From there you can browse for the .nbm file and hit install. You must be using Netbeans 6.9.
I make no promises as to its stability at this point - but if you give it a shot I guarantee you won't be disappointed with how easy/fast the Palette items make coding!
Note:
To get the palette items to show up, simply open a .php file (or any file you have associated with php in netbeans) and you will see a section of the palette show up called 'QCodo Controls'.
I don't use Netbeans but I might give this a try. I really like the palette idea, I think it is what is missing with QCubed. This would make for a more Visual Studio type development environment. Will let you know what I think when I have a chance to try it out.
If your column width is less than the filter box width, this may be the issue Obviously the column can't shrink smaller than its contents. Right now filter box width is set via the column's FilterBoxSize property (in characters), and not derived from the overall column width.
That may be a nice improvement going forward, though I'm not sure how feasible it will be for columns without specified widths. :)
QCubed has a built in QApplication::Translate function, all you need to worry about is initializing it with the desired language, and having an appropriate .po file with the translations you need.
Check out /assets/_core/php/examples/communication/i18n.php in your local environment.
Just to put a point on it, my prod server is running 5.2.2 and has so many dependencies that upgrading at all is nearly impossible, let alone to 5.3. As such, I will be actively working to ensure QCubed works in that environment, as otherwise, it will not meet my needs.
I'm also very unclear of any significant benefits of 5.3 apart from namespaces, which would be too much work to retrofit into QCubed with no real benefit. What do you hope to gain by moving to 5.3 exclusively apart from being able to avoid checking if a function is backwards compatible?
Above instead of "the 2 cols and the inputs for filtering are the same width" i meant "all the 3 cols and the inputs for filtering are the same width".
ha ha, you're correct, I clearly need more coffee before I type sometimes. Correct, and this is probably why he's no longer getting a validation error (since he added the "visible=false" which removed the control from the page.
Actually, I think you have that reversed. Display controls the CSS to hide elements, while Visible controls whether the element is sent to the client at all.
Obviously invisible controls should not be validated. But non-displayed ones may be.
<?php class QUnorderedList extends QControl { protected $_arrList = array();
// Because we're generating a Block Element (at its core, the control is a // DIV with a bunch of stuff inside), let's set this to true. // (This is required for X/HTML Strict Standards Compliance) protected $blnIsBlockElement = true;
/** * If this control needs to update itself from the $_POST data, the logic to do so * will be performed in this method. */ public function ParsePostData() {}
/** * If this control has validation rules, the logic to do so * will be performed in this method. * @return boolean */ public function Validate() {return true;}
/** * Get the HTML for this Control. * @return string */ public function GetControlHtml() { // Pull any Attributes $strAttributes = $this->GetAttributes();
// Pull any styles if ($strStyle = $this->GetStyleAttributes()) $strStyle = 'style="' . $strStyle . '"';
/** * Constructor for this control * @param mixed $objParentObject Parent QForm or QControl that is responsible for rendering this control * @param string $strControlId optional control ID */ public function __construct($objParentObject, $strControlId = null) { try { parent::__construct($objParentObject, $strControlId); } catch (QCallerException $objExc) { $objExc->IncrementOffset(); throw $objExc; } }
public function HTMLList($array) { if (!is_array($array)) return $array; if (empty($array)) return ''; $list = '<ul>'."\n"; foreach ($array as $k => $v) $list .= '<li class="item'.$k.'">'.$this->HTMLList($v).'</li>'."\n"; $list .= '</ul>'."\n"; return $list; } } ?>
And then:
<?php class QMenu extends QUnorderedList { public $menu; protected $itemCounter = 0;
/** * If this control needs to update itself from the $_POST data, the logic to do so * will be performed in this method. */ public function ParsePostData() {}
/** * If this control has validation rules, the logic to do so * will be performed in this method. * @return boolean */ public function Validate() {return true;}
/** * Get the HTML for this Control. * @return string */ public function GetControlHtml() { $array = $this->menu; // Pull any Attributesarray( $strAttributes = $this->GetAttributes();
// Pull any styles if ($strStyle = $this->GetStyleAttributes()) $strStyle = 'style="' . $strStyle . '"';
// This should return a wonderful list suitable for a site navigation menu return $out; }
/** * Constructor for this control * @param mixed $objParentObject Parent QForm or QControl that is responsible for rendering this control * @param string $strControlId optional control ID */ public function __construct($objParentObject, $strControlId = null) { try { parent::__construct($objParentObject, $strControlId); } catch (QCallerException $objExc) { $objExc->IncrementOffset(); throw $objExc; } } public function AddItem($objItem) {
it's really weird that adding "Visible = false" would correct an issue like this. "Display" should be more destructive than "Visible".
"Visible" is more benign because it actually leaves the control on the page, just hides it. "Display" removes the control from the page (I guess you could say).
Your fix leads me to believe there is some glitch for how this information is inherits through the control hierarchy. Definitely a different issue that mine, but still related to inheritance. Glad you were able to find a workaround.
I'm using 2.0.1 and there is definitely something very strange going on. I've been trying to track down the bug for a good 6 hours now and can't seem to find out where it is going wrong.
For me, if I put controls in a QDialogBox it works fine, but if I put a metacontrol in the QDialogBox, then weird things start to happen, like a button on my form doesn't respond to actions anymore.
I have narrowed it down though so that this only happens if the metacontrol has a control on it that is marked as 'required'. So now I suspect it has something to do with form validation.
So, if you have a QDialogBox with a metacontrol on it that has, say, a selectbox that is marked as 'required', then a button on my main form does not seem to fire. Actually, I am assuming it is firing but failing validation in some way but I can't see the validation message because the QdialogBox is hidden.
After many hours of banging heads and tearing hair, I found a solution.
My QdialogBox has code like this:
$this->dlgAddTask = new AddTaskDialog('btnAddTask_Close', $this); $this->dlgAddTask->Title = "Add a Task"; $this->dlgAddTask->Display = false;
This is straight from the examples site.
Now the Qcubed validation rules should only apply to visible controls ( according to the examples site), but actually, the ->Display() function is not the right one for that, because this makes it work:
$this->dlgAddTask = new AddTaskDialog('btnAddTask_Close', $this); $this->dlgAddTask->Title = "Add a Task"; $this->dlgAddTask->Visible = false; $this->dlgAddTask->Display = false;
So the underlying issue for me was that ->Visible and ->Display do similar but not identical things. I assume this is due to the way that most of the jqueryUI component code was automatically generated and a small change needs to be made to the ->Display() function.
Your problem is probably different than mine, but perhaps this helps.
I have a patch for the Date issue. I'll be creating a ticket and attaching a patch shortly. Also, QJqButton doesn't take ->Text (it has ->Label) and I have a patch for that too.
I have a similar issue. I have a form that has a button that shows a QDialogBox. The QDialogBox has a metacontrol.
This works fine _if_ I create the metacontrol with CreateFromPathInfo($this); If I just use Create($this), then several things break, like actions don't fire on buttons on my main form, and I can't actually use the metacontrol in the QDialogBox to create new objects.
The dialog still shows in both cases and the metacontrol renders, but there is an error somewhere.
Yeah, officially, RHEL 5.5 (the latest) only supports PHP 5.1.6, so in the interests of being usable in the enterprise, I want to maintain compatibility with that.
RHEL 6.0 will introduce support for PHP 5.3.1, but isn't out yet, and will take quite a while to gain widespread adoption.
I want to be very cautious about this. There are many _MANY_ enterprise servers out there running very strictly controlled OS builds, such as RHEL, and not all of them (not even RHEL, I believe) officially support PHP 5.3 yet.
Since maintaining backwards compatibility with PHP 5.1 is so trivially easy (don't use any of the esoteric newly added features), I'd hate to alienate anyone using enterprise server software over it.
The google maps code was wrapped up nicely by scott into a plugin: see it in action here - http://examples.qcu.be/assets/plugins/QGoogleMap/example/QGoogleMapExamp...
Download it here: http://trac.qcu.be/projects/qcubed/wiki/plugins
Thank you for your detailed post.
online payday loan lenders
hello Alex94040,
Can you send me project with google maps please?
Thanks.
I did some minor work on this tonight and I have QTextBoxes working a lot better, and added in basic support for QLinkButtons. I also posted a .nbm, which you can find in the downloads section on the Google code website http://code.google.com/p/qcodo-netbeans-tools/. You can install it by going to Tools->Plugins and clicking on the 'Downloads' tab. From there you can browse for the .nbm file and hit install. You must be using Netbeans 6.9.
I make no promises as to its stability at this point - but if you give it a shot I guarantee you won't be disappointed with how easy/fast the Palette items make coding!
Note:
To get the palette items to show up, simply open a .php file (or any file you have associated with php in netbeans) and you will see a section of the palette show up called 'QCodo Controls'.
Let me know of any thoughts!
I don't use Netbeans but I might give this a try. I really like the palette idea, I think it is what is missing with QCubed. This would make for a more Visual Studio type development environment. Will let you know what I think when I have a chance to try it out.
If your column width is less than the filter box width, this may be the issue Obviously the column can't shrink smaller than its contents. Right now filter box width is set via the column's FilterBoxSize property (in characters), and not derived from the overall column width.
That may be a nice improvement going forward, though I'm not sure how feasible it will be for columns without specified widths. :)
QCubed has a built in QApplication::Translate function, all you need to worry about is initializing it with the desired language, and having an appropriate .po file with the translations you need.
Check out /assets/_core/php/examples/communication/i18n.php in your local environment.
(Normally, I'd say http://examples.qcu.be/assets/_core/php/examples/communication/i18n.php but it's misconfigured)
Just to put a point on it, my prod server is running 5.2.2 and has so many dependencies that upgrading at all is nearly impossible, let alone to 5.3. As such, I will be actively working to ensure QCubed works in that environment, as otherwise, it will not meet my needs.
I'm also very unclear of any significant benefits of 5.3 apart from namespaces, which would be too much work to retrofit into QCubed with no real benefit. What do you hope to gain by moving to 5.3 exclusively apart from being able to avoid checking if a function is backwards compatible?
Above instead of "the 2 cols and the inputs for filtering are the same width" i meant "all the 3 cols and the inputs for filtering are the same width".
Wow! Cool Scott! Thanks!
Yes, I have been meaning to. I'll try to get to that ASAP.
You guys rock!!
It is a great idea to go for 5.3.
AFAIK
ZF 2 will be exclusive 5.3
Doctrine 2 same.
It is where a new generation of frameworks is now possible.
5.3 is the future and we will not look back in a few months.
Cheers,
tronics
ha ha, you're correct, I clearly need more coffee before I type sometimes. Correct, and this is probably why he's no longer getting a validation error (since he added the "visible=false" which removed the control from the page.
thanks for the correction!
Scott - do you want to wrap up these two interesting controls into a plugin?
Actually, I think you have that reversed. Display controls the CSS to hide elements, while Visible controls whether the element is sent to the client at all.
Obviously invisible controls should not be validated. But non-displayed ones may be.
Here are two QControls that may help:
<?php
class QUnorderedList extends QControl {
protected $_arrList = array();
// Because we're generating a Block Element (at its core, the control is a
// DIV with a bunch of stuff inside), let's set this to true.
// (This is required for X/HTML Strict Standards Compliance)
protected $blnIsBlockElement = true;
/**
* If this control needs to update itself from the $_POST data, the logic to do so
* will be performed in this method.
*/
public function ParsePostData() {}
/**
* If this control has validation rules, the logic to do so
* will be performed in this method.
* @return boolean
*/
public function Validate() {return true;}
/**
* Get the HTML for this Control.
* @return string
*/
public function GetControlHtml() {
// Pull any Attributes
$strAttributes = $this->GetAttributes();
// Pull any styles
if ($strStyle = $this->GetStyleAttributes())
$strStyle = 'style="' . $strStyle . '"';
return sprintf('<div id="%s" %s%s>%s</div>',$this->strControlId, $strAttributes, $strStyle,$this->HTMLList($this->_arrList));
}
/**
* Constructor for this control
* @param mixed $objParentObject Parent QForm or QControl that is responsible for rendering this control
* @param string $strControlId optional control ID
*/
public function __construct($objParentObject, $strControlId = null) {
try {
parent::__construct($objParentObject, $strControlId);
} catch (QCallerException $objExc) { $objExc->IncrementOffset(); throw $objExc; }
}
public function AddListItem($array) {
try {
$this->_arrList = array_merge_recursive($this->_arrList , $array);
} catch (QCallerException $objExc) { $objExc->IncrementOffset(); throw $objExc; }
}
public function HTMLList($array) {
if (!is_array($array)) return $array;
if (empty($array)) return '';
$list = '<ul>'."\n";
foreach ($array as $k => $v)
$list .= '<li class="item'.$k.'">'.$this->HTMLList($v).'</li>'."\n";
$list .= '</ul>'."\n";
return $list;
}
}
?>
And then:
<?php
class QMenu extends QUnorderedList {
public $menu;
protected $itemCounter = 0;
/**
* If this control needs to update itself from the $_POST data, the logic to do so
* will be performed in this method.
*/
public function ParsePostData() {}
/**
* If this control has validation rules, the logic to do so
* will be performed in this method.
* @return boolean
*/
public function Validate() {return true;}
/**
* Get the HTML for this Control.
* @return string
*/
public function GetControlHtml() {
$array = $this->menu;
// Pull any Attributesarray(
$strAttributes = $this->GetAttributes();
// Pull any styles
if ($strStyle = $this->GetStyleAttributes())
$strStyle = 'style="' . $strStyle . '"';
// Start Output of QMenu
$out = sprintf("\t".'<ul id="%s" %s%s>'."\r\n", $this->strControlId, $strAttributes, $strStyle);
for ( $i = 1; $i <= count( $array ); $i++ ) {
if ( is_array( $array[$i] ) ) {
if ( $array[$i]['show'] && $array[$i]['parent'] == 0 ) {
$out .= "\t\t".'<li class="parentMenu"><span><a href="' . $array[$i]['link'] . '">';
$out .= $array[$i]['label'];
$out .= '</a></span>';
$out .= $this->getChildren( $array, $i );
$out .= '</li>' . "\r\n";
}
} else {
$objExc->IncrementOffset();
throw $objExc;
}
}
$out .= "\t</ul>\r\n";
// This should return a wonderful list suitable for a site navigation menu
return $out;
}
/**
* Constructor for this control
* @param mixed $objParentObject Parent QForm or QControl that is responsible for rendering this control
* @param string $strControlId optional control ID
*/
public function __construct($objParentObject, $strControlId = null) {
try {
parent::__construct($objParentObject, $strControlId);
} catch (QCallerException $objExc) { $objExc->IncrementOffset(); throw $objExc; }
}
public function AddItem($objItem) {
}
public function AddMenuItem($label, $link= '#', $parent = 0, $show = TRUE) {
$this->itemCounter++;
try {
$this->menu[$this->itemCounter] = array(
'label' => $label,
'link' => $link,
'parent'=> $parent,
'show' => $show
);
} catch (QCallerException $objExc) { $objExc->IncrementOffset(); throw $objExc; }
}
public function getChildren( $array, $id ){
$isChild = FALSE;
$out = "\t<ul>\r\n";
for ( $i = 1; $i <= count( $array ); $i++ ){
if ( $array[$i]['show'] && $array[$i]['parent'] == $id ) {
$isChild = TRUE;
$out .= "\t\t".'<li class="childMenu"><span><a href="'.$array[$i]['link'].'">'.$array[$i]['label'].'</a>' . $this->getChildren( $array, $i ) . "</span></li>\r\n";
}
}
$out .= "\t</ul>\r\n";
return($isChild) ? $out : FALSE;
}
}
?>
it's really weird that adding "Visible = false" would correct an issue like this. "Display" should be more destructive than "Visible".
"Visible" is more benign because it actually leaves the control on the page, just hides it. "Display" removes the control from the page (I guess you could say).
Your fix leads me to believe there is some glitch for how this information is inherits through the control hierarchy. Definitely a different issue that mine, but still related to inheritance. Glad you were able to find a workaround.
I'm using 2.0.1 and there is definitely something very strange going on. I've been trying to track down the bug for a good 6 hours now and can't seem to find out where it is going wrong.
For me, if I put controls in a QDialogBox it works fine, but if I put a metacontrol in the QDialogBox, then weird things start to happen, like a button on my form doesn't respond to actions anymore.
I have narrowed it down though so that this only happens if the metacontrol has a control on it that is marked as 'required'. So now I suspect it has something to do with form validation.
So, if you have a QDialogBox with a metacontrol on it that has, say, a selectbox that is marked as 'required', then a button on my main form does not seem to fire. Actually, I am assuming it is firing but failing validation in some way but I can't see the validation message because the QdialogBox is hidden.
After many hours of banging heads and tearing hair, I found a solution.
My QdialogBox has code like this:
$this->dlgAddTask = new AddTaskDialog('btnAddTask_Close', $this);$this->dlgAddTask->Title = "Add a Task";
$this->dlgAddTask->Display = false;
This is straight from the examples site.
Now the Qcubed validation rules should only apply to visible controls ( according to the examples site), but actually, the ->Display() function is not the right one for that, because this makes it work:
$this->dlgAddTask = new AddTaskDialog('btnAddTask_Close', $this);$this->dlgAddTask->Title = "Add a Task";
$this->dlgAddTask->Visible = false;
$this->dlgAddTask->Display = false;
So the underlying issue for me was that ->Visible and ->Display do similar but not identical things. I assume this is due to the way that most of the jqueryUI component code was automatically generated and a small change needs to be made to the ->Display() function.
Your problem is probably different than mine, but perhaps this helps.
Ok; thanks a lot for your answers.
Sweet! Thanks, cliff!
I have a patch for the Date issue. I'll be creating a ticket and attaching a patch shortly. Also, QJqButton doesn't take ->Text (it has ->Label) and I have a patch for that too.
I have a similar issue. I have a form that has a button that shows a QDialogBox. The QDialogBox has a metacontrol.
This works fine _if_ I create the metacontrol with CreateFromPathInfo($this); If I just use Create($this), then several things break, like actions don't fire on buttons on my main form, and I can't actually use the metacontrol in the QDialogBox to create new objects.
The dialog still shows in both cases and the metacontrol renders, but there is an error somewhere.
Yeah, officially, RHEL 5.5 (the latest) only supports PHP 5.1.6, so in the interests of being usable in the enterprise, I want to maintain compatibility with that.
RHEL 6.0 will introduce support for PHP 5.3.1, but isn't out yet, and will take quite a while to gain widespread adoption.
I want to be very cautious about this. There are many _MANY_ enterprise servers out there running very strictly controlled OS builds, such as RHEL, and not all of them (not even RHEL, I believe) officially support PHP 5.3 yet.
Since maintaining backwards compatibility with PHP 5.1 is so trivially easy (don't use any of the esoteric newly added features), I'd hate to alienate anyone using enterprise server software over it.