yii - Google Code

Today 10 min ago r1203 (Added CForm::validate().) committed by qiang.xue - Added CForm::validate(). Added CForm::validate(). 34 min ago r1202 (merge from 1.0) committed by qiang.xue - merge from 1.0 merge from 1.0 41 min ago r1201 ([No log message]) committed by qiang.xue - [No log message] [No log message] 44 min ago issue 422 (Typo error - The Yii Blog Tutorial - Displaying Posts) Status changed by qiang.xue - This issue was closed by r1200. Status: Fixed This issue was closed by r1200. Status: Fixed 45 min ago r1200 ((Fixes issue 422)) committed by qiang.xue - (Fixes issue 422 ) (Fixes issue 422 ) 80 min ago issue 422 (Typo error - The Yii Blog Tutorial - Displaying Posts) reported by eleni.fra - Section <Customizing show Operation>: In the example a 404 error is produced if the post is not found or it's not published yet. In the paragraph that follows, a 500 error is mentioned instead. Section <Customizing show Operation>: In the example a 404 error is produced if the post is not found or it's not published yet. In the paragraph that follows, a 500 error is mentioned instead. 4 hours ago issue 421 (Undefined variable: seconds in CDateTimeParser.php(140)) Status changed by qiang.xue - This issue was closed by r1199. Status: Fixed This issue was closed by r1199. Status: Fixed 4 hours ago r1199 ((Fixes issue 421)) committed by qiang.xue - (Fixes issue 421 ) (Fixes issue 421 ) 4 hours ago issue 421 (Undefined variable: seconds in CDateTimeParser.php(140)) Labels changed by qiang.xue - Labels: Type-Defect Labels: Type-Defect 4 hours ago issue 421 (Undefined variable: seconds in CDateTimeParser.php(140)) reported by Razunter - case 's': { if(($second=self::parseInteger($value,$i,1,2))===false) return false; $i+=strlen($seconds); break; } $seconds should be $second case 's': { if(($second=self::parseInteger($value,$i,1,2))===false) return false; $i+=strlen($seconds); break; } $seconds should be $second 4 hours ago issue 417 (Add beforeFind() function) Labels changed by qiang.xue - Need more thinking. Adding beforeFind() is not the best solution because it won't work for related queries. The requirement here should be described as: provide a way to allow behaviors to modify defaultScope(). Labels: Milestone-1.0.8 −Milestone-1.0.7 Need more thinking. Adding beforeFind() is not the best solution because it won't work for related queries. The requirement here should be described as: provide a way to allow behaviors to modify defaultScope(). Labels: Milestone-1.0.8 −Milestone-1.0.7 Last 7 days Jul 02, 2009 issue 420 (Add section about behaviors + events to the guide) Labels changed by qiang.xue - Labels: Milestone-1.0.8 −Milestone-1.0.7 Labels: Milestone-1.0.8 −Milestone-1.0.7 Jul 02, 2009 issue 420 (Add section about behaviors + events to the guide) reported by haertl.mike - The guide mentions the power of behaviors + events but doesn't explain how to use them. The guide mentions the power of behaviors + events but doesn't explain how to use them. Jul 01, 2009 issue 419 (SQL optimization) Labels changed by qiang.xue - Labels: Milestone-1.0.8 −Milestone-1.1a Labels: Milestone-1.0.8 −Milestone-1.1a Jul 01, 2009 issue 419 (SQL optimization) Labels changed by qiang.xue - Labels: Milestone-1.1a −Milestone-1.0.7 Labels: Milestone-1.1a −Milestone-1.0.7 Jul 01, 2009 r1198 (* Added userAgent parameter to CHttpRequest::getBrowser().) committed by qiang.xue - * Added userAgent parameter to CHttpRequest::getBrowser(). * Added userAgent parameter to CHttpRequest::getBrowser(). Jul 01, 2009 issue 419 (SQL optimization) reported by istvan.beregszaszi - Original topic: http://www.yiiframework.com/forum/index.php/topic,3028.0.html Related article: http://en.netlog.com/developers/blog/blogid=3071854. The discussion was about to add support for sherding. I'll bring another idea to surface, as it can provide significant performance gain. Adding another switch to models would be great to let records be populated in two steps: first, only primary keys are returned while conditions and ordering are being applied; selected fields only return in the subsequent query. More reading about this: http://www.codinghorror.com/blog/archives/001281.html Original topic: http://www.yiiframework.com/forum/index.php/topic,3028.0.html Related article: http://en.netlog.com/developers/blog/blogid=3071854. The discussion was about to add support for sherding. I'll bring another idea to surface, as it can provide significant performance gain. Adding another switch to models would be great to let records be populated in two steps: first, only primary keys are returned while conditions and ordering are being applied; selected fields only return in the subsequent query. More reading about this: http://www.codinghorror.com/blog/archives/001281.html Jul 01, 2009 issue 417 (Add beforeFind() function) commented on by istvan.beregszaszi - abstract class CustomActiveRecord extends CActiveRecord { public function onBeforeFind($event) { $this->raiseEvent('onBeforeSave', $event); } // Make sure you call the parent implementation protected function beforeFind() { $this->onBeforeFind(new CEvent($this)); } private function query($criteria,$all=false) { $this->beforeFind(); parent::query($criteria,$all); } } This should do as a base AR class as long as you want to raise the beforeFind() event before the query. You can attach behaviors, too. However, if you want to have an event run before the populated models are usable, then I'd recommend to extend afterConstruct event instead. abstract class CustomActiveRecord extends CActiveRecord { public function onBeforeFind($event) { $this->raiseEvent('onBeforeSave', $event); } // Make sure you call the parent implementation protected function beforeFind() { $this->onBeforeFind(new CEvent($this)); } private function query($criteria,$all=false) { $this->beforeFind(); parent::query($criteria,$all); } } This should do as a base AR class as long as you want to raise the beforeFind() event before the query. You can attach behaviors, too. However, if you want to have an event run before the populated models are usable, then I'd recommend to extend afterConstruct event instead. Jun 30, 2009 issue 417 (Add beforeFind() function) commented on by willsp - istvan.. not necessarily. Today I tried to implement a softdelete behavior and unfortunately had to withdraw for lack of beforeFind. Try to figure out when a softdelete behavior is attached to a model, all find operations should be merged to meet a condition for the deleted column of the table in the database. Without beforeFind become impossible since it is not possible to overwrite the method defaultScope the model from a behavior (i guess).. istvan.. not necessarily. Today I tried to implement a softdelete behavior and unfortunately had to withdraw for lack of beforeFind. Try to figure out when a softdelete behavior is attached to a model, all find operations should be merged to meet a condition for the deleted column of the table in the database. Without beforeFind become impossible since it is not possible to overwrite the method defaultScope the model from a behavior (i guess).. Jun 30, 2009 issue 418 (CMssqlSchema class contains comments from CMysqlSchema) Status changed by qiang.xue - This issue was closed by r1197. Status: Fixed This issue was closed by r1197. Status: Fixed Jun 30, 2009 r1197 ((Fixes issue 418) documentation error.) committed by qiang.xue - (Fixes issue 418 ) documentation error. (Fixes issue 418 ) documentation error. Jun 30, 2009 issue 418 (CMssqlSchema class contains comments from CMysqlSchema) reported by oleg.anashkin - Apparently, this is copy/paste inheritance bug :) Apparently, this is copy/paste inheritance bug :) Jun 30, 2009 issue 131 (Add payment processors support) commented on by istvan.beregszaszi - I will definitely use this - hopefully as an extension. I will definitely use this - hopefully as an extension. Jun 30, 2009 issue 417 (Add beforeFind() function) commented on by istvan.beregszaszi - I think what you need is CActiveRecord::defaultScope(). I think what you need is CActiveRecord::defaultScope(). Jun 30, 2009 issue 416 (GetSubProperty/SetSubProperty are missing.) commented on by qiang.xue - Yes, it's a habit. Besides performance, the other reason that we don't want to implement this is about learning curve. We want to keep everything as natural as possible. Thanks for discussion. Yes, it's a habit. Besides performance, the other reason that we don't want to implement this is about learning curve. We want to keep everything as natural as possible. Thanks for discussion. Jun 30, 2009 issue 416 (GetSubProperty/SetSubProperty are missing.) commented on by sergeymorkovkin - Convinced. Thanks for help. Objects can also be configured this way easily. No I see this was more likely a matter of habit. Convinced. Thanks for help. Objects can also be configured this way easily. No I see this was more likely a matter of habit. Jun 30, 2009 issue 416 (GetSubProperty/SetSubProperty are missing.) commented on by qiang.xue - Not convinced. For the widget-defined default values, you could do: $defaults=array_merge($defaults, $this->htmlOptions); Then you no longer need those checks. Not convinced. For the widget-defined default values, you could do: $defaults=array_merge($defaults, $this->htmlOptions); Then you no longer need those checks. Jun 30, 2009 issue 416 (GetSubProperty/SetSubProperty are missing.) commented on by sergeymorkovkin - The problem I imply here is described below. There is no core mechanism to set one or several values of an array. All you can do is override entire array. Here's an example (TSomeWidget): public $htmlOptions = array('class' => 'some', 'style' => 'width: 100px'); <? $this->beginWidget('TSomeWidget', array('htmlOptions' => array(...))) ?> Notice the place I marked with '...'. There you need to repeat all widget-defined array values to add some attribute to the widget. Of course, this is all about convenience. Just comparing Prado's XML approach with YII's PHP. Isn't it possible to implement some mechanism so we could override magic methods using behaviors? For example, dot-format could be something like: <? $this->beginWidget('TSomeWidget', array('htmlOptions.class' => 'new_class')) ?> In this situation existing array values would be preserved. If you care about performance, the following might be an alternative (thought it's complicated): <? $this->beginWidget('TSomeWidget', array('prop:htmlOptions.class' => 'new_one')) ?> Where 'prop:' would invoke/autoload a behavior named 'prop' responding for assigning sub-property values. Prop might also be a method autoloading matching behavior. In fact, this is not a matter of XML/PHP-based approach but an implementation. Prado allows dotted property assignment while YII doesn't. This will definitely save developers from writing tons of dummy lines of code such as: $htmlOptions = $this->htmlOptions; if (!empty($this->class)) $htmlOptions['class'] = $this->class; if (!empty($this->style)) $htmlOptions['style'] = $this->style; $labelOptions = $this->htmlOptions; if (!empty($this->class)) $labelOptions['class'] = $this->class; if (!empty($this->style)) $labelOptions['style'] = $this->style; $inputOptions = $this->htmlOptions; if (!empty($this->class)) $inputOptions['class'] = $this->class; if (!empty($this->style)) $inputOptions['style'] = $this->style; The problem I imply here is described below. There is no core mechanism to set one or several values of an array. All you can do is override entire array. Here's an example (TSomeWidget): public $htmlOptions = array('class' => 'some', 'style' => 'width: 100px'); <? $this->beginWidget('TSomeWidget', array('htmlOptions' => array(...))) ?> Notice the place I marked with '...'. There you need to repeat all widget-defined array values to add some attribute to the widget. Of course, this is all about convenience. Just comparing Prado's XML approach with YII's PHP. Isn't it possible to implement some mechanism so we could override magic methods using behaviors? For example, dot-format could be something like: <? $this->beginWidget('TSomeWidget', array('htmlOptions.class' => 'new_class')) ?> In this situation existing array values would be preserved. If you care about performance, the following might be an alternative (thought it's complicated): <? $this->beginWidget('TSomeWidget', array('prop:htmlOptions.class' => 'new_one')) ?> Where 'prop:' would invoke/autoload a behavior named 'prop' responding for assigning sub-property values. Prop might also be a method autoloading matching behavior. In fact, this is not a matter of XML/PHP-based approach but an implementation. Prado allows dotted property assignment while YII doesn't. This will definitely save developers from writing tons of dummy lines of code such as: $htmlOptions = $this->htmlOptions; if (!empty($this->class)) $htmlOptions['class'] = $this->class; if (!empty($this->style)) $htmlOptions['style'] = $this->style; $labelOptions = $this->htmlOptions; if (!empty($this->class)) $labelOptions['class'] = $this->class; if (!empty($this->style)) $labelOptions['style'] = $this->style; $inputOptions = $this->htmlOptions; if (!empty($this->class)) $inputOptions['class'] = $this->class; if (!empty($this->style)) $inputOptions['style'] = $this->style; Jun 30, 2009 r1196 (Fixed the bug that when using MySQL enum type, AR may incorr...) committed by qiang.xue - Fixed the bug that when using MySQL enum type, AR may incorrectly typcasting the column values. Fixed the bug that when using MySQL enum type, AR may incorrectly typcasting the column values. Jun 30, 2009 issue 415 (CHtml::errorSummary doesn't offer htmlOptions parameter.) Status changed by qiang.xue - This issue was closed by r1195. Status: Fixed This issue was closed by r1195. Status: Fixed Jun 30, 2009 r1195 (* (Fixes issue 415) Added HTML options to CHtml::errorSummar...) committed by qiang.xue - * (Fixes issue 415 ) Added HTML options to CHtml::errorSummary() and error() methods. * (Fixes issue 415 ) Added HTML options to CHtml::errorSummary() and error() methods. Jun 30, 2009 issue 417 (Add beforeFind() function) reported by glen.84 - I really need this, useful for attaching extra conditions before a find operation. Function would be invoked in populateRecord/s(), I assume. I really need this, useful for attaching extra conditions before a find operation. Function would be invoked in populateRecord/s(), I assume. Jun 30, 2009 issue 416 (GetSubProperty/SetSubProperty are missing.) Status changed by qiang.xue - Prado needs it because its configuration is XML based while Yii is PHP based. For this reason, sub-property is not used in Yii. Will not support this. Status: WontFix Prado needs it because its configuration is XML based while Yii is PHP based. For this reason, sub-property is not used in Yii. Will not support this. Status: WontFix Jun 30, 2009 issue 416 (GetSubProperty/SetSubProperty are missing.) reported by sergeymorkovkin - While Prado was a bit slower, it offered those methods making it easy to configure object-containing properties. I assume you didn't include this functionality into YII because of performance issues. Though, you might preserve it as an optional part of CComponent. While Prado was a bit slower, it offered those methods making it easy to configure object-containing properties. I assume you didn't include this functionality into YII because of performance issues. Though, you might preserve it as an optional part of CComponent. Jun 30, 2009 issue 415 (CHtml::errorSummary doesn't offer htmlOptions parameter.) reported by sergeymorkovkin - Thus, no control over container tag unlike in other helper functions. Thus, no control over container tag unlike in other helper functions. Jun 29, 2009 r1194 (merge from 1.0) committed by qiang.xue - merge from 1.0 merge from 1.0 Jun 29, 2009 issue 375 (Allow to preserve session data on logout) Status changed by qiang.xue - This issue was closed by r1193. Status: Fixed This issue was closed by r1193. Status: Fixed Jun 29, 2009 r1193 (* (Fixes issue 375) Added support to allow logout a user wit...) committed by qiang.xue - * (Fixes issue 375 ) Added support to allow logout a user without cleaning up non-auth session data. * (Fixes issue 375 ) Added support to allow logout a user without cleaning up non-auth session data. Jun 29, 2009 r1192 (CWebUser minor refactoring) committed by qiang.xue - CWebUser minor refactoring CWebUser minor refactoring Jun 29, 2009 r1191 ([No log message]) committed by qiang.xue - [No log message] [No log message] Jun 29, 2009 issue 367 (CUploadedFile::getInstance() crashes with PHP error) Status changed by qiang.xue - This issue was closed by r1190. Status: Fixed This issue was closed by r1190. Status: Fixed Jun 29, 2009 r1190 ((Fixes issue 367) CUploadedFile may fail if a form contains ...) committed by qiang.xue - (Fixes issue 367 ) CUploadedFile may fail if a form contains multiple file uploads in different array dimensions (Fixes issue 367 ) CUploadedFile may fail if a form contains multiple file uploads in different array dimensions Jun 29, 2009 issue 368 (CUploadedFile::getInstance() not returns null if no file was...) Status changed by qiang.xue - This issue was closed by r1189. Status: Fixed This issue was closed by r1189. Status: Fixed Jun 29, 2009 r1189 ((Fixes issue 368) CUploadedFile::getInstance() should return...) committed by qiang.xue - (Fixes issue 368 ) CUploadedFile::getInstance() should return null if no file is uploaded (Fixes issue 368 ) CUploadedFile::getInstance() should return null if no file is uploaded Jun 29, 2009 r1188 (label generation fix.) committed by qiang.xue - label generation fix. label generation fix. Jun 29, 2009 issue 413 (Handling Errors Using an Action does not work as expected) Status changed by qiang.xue - Status: Invalid Status: Invalid Jun 29, 2009 issue 413 (Handling Errors Using an Action does not work as expected) commented on by sven.kauber - Thanks, Qiang, for pointing me to the right direction. I just tested with an empty webapp and after going through all the steps, the result was a success. Should have done this test before posting. I'll do some more checks myself. Thanks, Qiang, for pointing me to the right direction. I just tested with an empty webapp and after going through all the steps, the result was a success. Should have done this test before posting. I'll do some more checks myself. Jun 28, 2009 issue 414 (Invert validator behaviour option) Status changed by qiang.xue - Will not implement this because it makes the usage twister, even though the implementation is trivial. It also has side effects (e.g. if you set invert=true for a 'required' validator, it would make isAttributeRequired() method more complicated). For CRegularExpressionValidator, it should be possible to write a regex that ensures the input does not match the given words. Status: WontFix Will not implement this because it makes the usage twister, even though the implementation is trivial. It also has side effects (e.g. if you set invert=true for a 'required' validator, it would make isAttributeRequired() method more complicated). For CRegularExpressionValidator, it should be possible to write a regex that ensures the input does not match the given words. Status: WontFix Jun 28, 2009 issue 403 (scenario change in beforeValidate is ignored in validate) commented on by sluderitz - Ok, its not a big deal. Example for usage: Say you have active record "Person", it contains a field "person_type". For certain person types you might want the field "birthday" to be required. You could hide that logic in the AR completely, by checking for person type and chosing the 2. scenario in beforeValidate(). In version 1.0.6. you have to check in the controller and then set the scenario there. Doing it in beforeValidate() is more elegant for this case I think. Ok, its not a big deal. Example for usage: Say you have active record "Person", it contains a field "person_type". For certain person types you might want the field "birthday" to be required. You could hide that logic in the AR completely, by checking for person type and chosing the 2. scenario in beforeValidate(). In version 1.0.6. you have to check in the controller and then set the scenario there. Doing it in beforeValidate() is more elegant for this case I think. Jun 28, 2009 issue 412 (CDateTimeParser should support milliseconds and time zones, ...) Labels changed by qiang.xue - This is beyond the original design scope. Postpone it to 1.1 or future. Labels: Milestone-1.1a −Milestone-1.0.7 This is beyond the original design scope. Postpone it to 1.1 or future. Labels: Milestone-1.1a −Milestone-1.0.7

issue 416 (GetSubProperty/SetSubProperty are missing.) commented on by sergeymorkovkin - The problem I imply here is described below. There is no core mechanism to set one or several values of an array. All you can do is override entire array. Here's an example (TSomeWidget): public $htmlOptions = array('class' => 'some', 'style' => 'width: 100px'); <? $this->beginWidget('TSomeWidget', array('htmlOptions' => array(...))) ?> Notice the place I marked with '...'. There you need to repeat all widget-defined array values to add some attribute to the widget. Of course, this is all about convenience. Just comparing Prado's XML approach with YII's PHP. Isn't it possible to implement some mechanism so we could override magic methods using behaviors? For example, dot-format could be something like: <? $this->beginWidget('TSomeWidget', array('htmlOptions.class' => 'new_class')) ?> In this situation existing array values would be preserved. If you care about performance, the following might be an alternative (thought it's complicated): <? $this->beginWidget('TSomeWidget', array('prop:htmlOptions.class' => 'new_one')) ?> Where 'prop:' would invoke/autoload a behavior named 'prop' responding for assigning sub-property values. Prop might also be a method autoloading matching behavior. In fact, this is not a matter of XML/PHP-based approach but an implementation. Prado allows dotted property assignment while YII doesn't. This will definitely save developers from writing tons of dummy lines of code such as: $htmlOptions = $this->htmlOptions; if (!empty($this->class)) $htmlOptions['class'] = $this->class; if (!empty($this->style)) $htmlOptions['style'] = $this->style; $labelOptions = $this->htmlOptions; if (!empty($this->class)) $labelOptions['class'] = $this->class; if (!empty($this->style)) $labelOptions['style'] = $this->style; $inputOptions = $this->htmlOptions; if (!empty($this->class)) $inputOptions['class'] = $this->class; if (!empty($this->style)) $inputOptions['style'] = $this->style;

The problem I imply here is described below. There is no core mechanism to set one or several values of an array. All you can do is override entire array. Here's an example (TSomeWidget): public $htmlOptions = array('class' => 'some', 'style' => 'width: 100px'); <? $this->beginWidget('TSomeWidget', array('htmlOptions' => array(...))) ?> Notice the place I marked with '...'. There you need to repeat all widget-defined array values to add some attribute to the widget. Of course, this is all about convenience. Just comparing Prado's XML approach with YII's PHP. Isn't it possible to implement some mechanism so we could override magic methods using behaviors? For example, dot-format could be something like: <? $this->beginWidget('TSomeWidget', array('htmlOptions.class' => 'new_class')) ?> In this situation existing array values would be preserved. If you care about performance, the following might be an alternative (thought it's complicated): <? $this->beginWidget('TSomeWidget', array('prop:htmlOptions.class' => 'new_one')) ?> Where 'prop:' would invoke/autoload a behavior named 'prop' responding for assigning sub-property values. Prop might also be a method autoloading matching behavior. In fact, this is not a matter of XML/PHP-based approach but an implementation. Prado allows dotted property assignment while YII doesn't. This will definitely save developers from writing tons of dummy lines of code such as: $htmlOptions = $this->htmlOptions; if (!empty($this->class)) $htmlOptions['class'] = $this->class; if (!empty($this->style)) $htmlOptions['style'] = $this->style; $labelOptions = $this->htmlOptions; if (!empty($this->class)) $labelOptions['class'] = $this->class; if (!empty($this->style)) $labelOptions['style'] = $this->style; $inputOptions = $this->htmlOptions; if (!empty($this->class)) $inputOptions['class'] = $this->class; if (!empty($this->style)) $inputOptions['style'] = $this->style;

Today

Last 7 days