*testcode to reproduce error:*
<?php
ini_set('magic_quotes_gpc', 'off');
require_once 'Zend/Loader.php';
/**
* Loads all Zend Framework classes automagically
*
* @param string $className
*/
function __autoload($className){
Zend_Loader::loadClass($className);
}
$view = new Zend_View();
$form = new ZendX_JQuery_Form();
$form->setView($view);
$form->addElement(new ZendX_JQuery_Form_Element_DatePicker("begin",
array('label' => 'begin', 'value' => '10-03-2008')));
echo $form;
$element = $form->getElement('begin');
$decorator = $element->getDecorator('UiWidgetElement');
$element->setDecorators(array('ViewHelper', $decorator));
$form->removeElement($begin);
$form->addElement($element);
echo $form;
*result:*
<form enctype="application/x-www-form-urlencoded" action=""
method="post"><dl class="zend_form">
<dt><label for="begin" class="optional">begin</label></dt>
<dd>
<input type="text" name="begin" id="begin"
value="10-03-2008"></dd></dl></form><br />
<b>Catchable fatal error</b>: Argument 4 passed to
ZendX_JQuery_View_Helper_DatePicker::datePicker() must be an array, null
given in
<b>E:\ZendFramework\library\ZendX\JQuery\View\Helper\DatePicker.php</b>
on line <b>54</b><br />
I am not trying to say you code your interface the wrong way. I only
noticed this behavior. In the process of fiddling with the decorators,
some piece of code is instantiating the DatePicker decorator with an
explicit null value as the fourth argument.
When you run my example, you will be able to see that this happens. With
rock solid OO design, I would expect the above example to run without
any problem. I can get the decorator, I should be allowed to put it back
in. With soft fail (without type hinting), I am allowed
to do so. Type hinting in general is considered bad practice by some
people, because it hinders soft fail.
I tried to run debug_backtrace on a larger form and that nearly crashed
my laptop. Maybe it can be run on this short example with success.
Bart
Benjamin Eberlei schreef:
Hello Bart,
the call signature for all jQuery helper mimics the dojo one:
$this->helper($id, $value, array $params=array(), array $attribs=array())
if you want to pass no value leave the parameter entry or put array() in it.
null leads to an error, this is desired behaviour.
regarding NULL and default value. This is correct PHP behaviour. Since NULL is
a type of variable it does not trigger usage of the default value which is
array(), but it passes NULL and "overrides" the default value. If you want to
default value to kick in you have to explicitly omit the parameter in the
call.
DatePicker has the following method signature:
public function datePicker($id, $value = null, array $params = array(), array
$attribs = array())
best regards,
Benjamin
On Sunday 26 October 2008 21:39:23 Bart McLeod wrote:
It seems to be by design, if explicit null values are passed in, the
default value is of no use:
<?php
function arrayDefault($par = array()){
if(! is_array($par)){
echo "problem", PHP_EOL ;
}else{
echo 'ok', PHP_EOL ;
}
}
arrayDefault();//ok
arrayDefault(NULL);//problem
function stringDefault($par = 'x'){
if(! is_string($par)){
echo "problem", PHP_EOL ;
}else{
echo 'ok', PHP_EOL ;
}
}
arrayDefault();//ok
arrayDefault(NULL);//problem
stringDefault();
stringDefault(null);
Bart McLeod schreef:
As and addition, I noticed that when putting
if(! is_array($attribs)){
var_dump($attribs);
//exit();
}
inside the function, is actually dumps NULL, while $attribs should be
Array{}, because the default is array(). PHP 5.2.5 doesn't seem to
assing the default value...
Regards,
Bart McLeod
Bart McLeod schreef:
Hi Benjamin,
I was able to remove the error by removing the type hints in your
interface. There is no point in having default values array() if you
are type hinting for array's. In that case, when the underlying
system passes in a null value, for whatever reason, the error will be
fatal.
public function datePicker($id, $value = null, *array* $params =
array(), *array *$attribs = array())
changed to:
public function datePicker($id, $value = null, $params = array(),
$attribs = array())
This way, if null is passed in, the default values will kick in. If
invalid values are passed in, I would recommend throwing a decent
exception when ! is_array($attribs). That way, it will be handled by
the errorController.
I thought the error was caused by my groupings: they remove all
decorators and put in their own. But your error persisted after I
handled this in a way that preserves the JQuery ui decorator. So
there was a problem under the hood, somehow.
I also noted that passing in the value has no effect.
$element->setValue($default) has. I also found no way to set the
label, other then through $element->setLabel(). Maybe I did not try
that last part hard enough.
Regards,
Bart McLeod
Bart McLeod schreef:
Hello Benjamin,
Yes, the decorators is exactly where I will have to be looking. The
reason that the 'begin' id caused the error is that the 'begin'
field is grouped together with other form elements automagically,
because I just hate to set decorators every time. It is more than
likely, that in the proces, the datepicker decorator is not added or
not configurated properly by this automatic proces.
I will run a test where I will var_dump the decorators before and
after grouping and look at the differences.
Can you give me the url to the closed bug? If I find something
useful, I would like to comment there.
Regards,
Bart McLeod
Benjamin Eberlei schreef:
Hello Bart,
ok i'll close it. In my opinion using the view helpers is really easy,
but the form elements are a bit hard to wield since the Element
Decorator structure is quite complex which spills to the jQuery
specific elements and decorators.
greetings,
Benjamin
On Thursday 23 October 2008 23:57:19 Bart McLeod wrote:
Hi Benjamin,
Yes and no. I know where to look to find out what is happening. It
would have been nice if this element would have been completely
compatible with all the tricks I play. For now, just close the
bugreport. If I find a compatibility issue later, that I can describe
more properly, I will let you know.
At the moment, I am a little sad that using jquery directly is
simpler than using its' ZF integrated counterpart. I was expecting
the opposite...but I will not give up yet.
Regards,
Bart
Benjamin Eberlei schreef:
so this is not at all ZendX_JQuery related? its due to your own
form implementation? i have already created a bug report, i will
close it then if you can confirm that.
On Thursday 23 October 2008 23:31:41 Bart McLeod wrote:
By now, I found that the error is due to some internal magic I use
for my forms. Still a strange error.
I was able to use a ZendX_JQuery_Form_Element_Datepicker, named
'begin' in a regular form that has no magic to it.
Bart
Bart McLeod schreef:
Hi all,
$elem = new ZendX_JQuery_Form_Element_DatePicker("begin",
"12.12.2007", array(), array());
$elem->setJQueryParam('dateFormat', 'dd.mm.yy');
$this->addElement($elem);
yields:
*Catchable fatal error*: Argument 4 passed to
ZendX_JQuery_View_Helper_DatePicker::datePicker() must be an
array, null given in
*E:\ZendFramework\library\ZendX\JQuery\View\Helper\DatePicker.php*
on line *54
*while:
$elem = new
ZendX_JQuery_Form_Element_DatePicker("*begin1*", "12.12.2007",
array(), array());
$elem->setJQueryParam('dateFormat', 'dd.mm.yy');
$this->addElement($elem);
gets a datepicker. See the difference? The id! The id cannot be
called 'begin'. It can be called 'begin1'. Maybe there is
something in my form magic that it causing this. So I should try
this without any magic, in a very simple form. Wanted to share it
with you before I forget.
Bart
