Beruflich Dokumente
Kultur Dokumente
Form Validation Can Only Use Controller's Method as Custom Callback Rule
If we want to apply a custom validation rule, we can use the Callback rule. But, Callback rule can only accept Controller's method. And that method must be publicly accessible. Remember that all publicly accessible method in Controller can also be accessed via browser (unnecessary route). It would be better if we can define any function/method as Callback rule. Solution: create a wrapper for form validation (Form_model class) that lets the use of method as validation
Form Validation Can Contain Only One Error Message Per Field
Suppose you define that a field has three validation rules. And the submitted value for that field violates all three rules. Form Validation will only show the error message for the first violation. Solution: either deal with it or extend CI_Form_validation
Unfortunately, there is no method for "empty rules" or "reset rules" or "reset the state of this library". Perhaps you are wondering "why not create another instance of Form Validation?", well CI does not work that way. Libraries and models are instantiated only once and then accessed globally. Solution: extend native libraries, add method to reset the state
Solution: delete that code, just like this pull request in CodeIgniter's repository
The intention of the statement is to call commit() method provided by PDO class. But the PDO driver class does not have conn attributes, but conn_id instead. As in trans_begin() method: r e t u r n$ t h i s > c o n n _ i d > b e g i n T r a n s a c t i o n ( ) ; Khandar traced back the commit log in GitHub and found the error was made in 2011-08-23 (Yes, 1.5 year ago!) but without any complaints or feedback about this. Link: http://git.jorgenio.com/codeigniter/commits/ab347586ef289e960ab7cfad32574e526cdcce0b 4. reconnect() method contains error (pdo_driver.php): f u n c t i o nr e c o n n e c t ( ) { i f( $ t h i s > d b > d b _ d e b u g ) { r e t u r n$ t h i s > d b > d i s p l a y _ e r r o r ( ' d b _ u n s u p o r t e d _ f e a t u r e ' ) ; } r e t u r nF A L S E ; } The class does not have db attributes, but only db_debug. This error raises warning in strict mode. Nobody has issued this in EllisLab. My conclusion: people who use CodeIgniter almost never use the PDO driver (hence nobody complains) and almost any pull/bug fix request will be replied with "already fixed in development branch" (development branch = CodeIgniter 3). Solution: if you are okay with modifying framework code (pdo_driver.php) #1 add $ t h i s > _ e s c a p e _ c h a r=' ` ' ;in constructor #2 change the line to $ t h i s > t r a n s _ e n a b l e d=T R U E ; #3 change the line to $ r e t=$ t h i s > c o n n > c o m m i t ( ) ; #4 change the line to i f( $ t h i s > d b _ d e b u g ) If you are not okay with modifying framework code either don't use the PDO driver (use the old mysql[i]) or use third party library why not just extend this class? have you read the guide? N o t e :T h eD a t a b a s ec l a s s e sc a nn o tb ee x t e n d e do rr e p l a c e dw i t hy o u ro w n c l a s s e s .A l lo t h e rc l a s s e sa r ea b l et ob er e p l a c e d / e x t e n d e d . still insist? join the Dark Side, use this hack to be able extend the database driver
The worst part? This only happens on the latest version (2.1.2-2.1.3), the older version doesn't have this issue. Maybe you are wondering why they need that i f ? Why not just use r o w C o u n t ( ) ? I think because it might not work for SELECT in some DBMS. Solution: extend pdo driver, take code from pdo driver in CI 3 method _ e x e c u t e ( )and a f f e c t e d _ r o w s ( )
Wait, what? Why? Because CI_Migration::__construct() forbid you to extend it #O n l yr u nt h i sc o n s t r u c t o ro nm a i nl i b r a r yl o a d i f( g e t _ p a r e n t _ c l a s s ( $ t h i s )! = =F A L S E ) { r e t u r n ; } What is the reason for this prohibition? The user guide didn't mention this. There are two people complaining about it and the best respond they get? "Seems pretty edge case. Just check the config." Didn't even tell why the restriction has to be there. Do you wanna know why? Migration has two components: the object that acts as migration (has up() and down() method) and the object that acts as migrator (can move version forward or backward). In CI, both objects have the same class: CI_Migration. I don't know why they design it that way, isn't a class is supposed to do one job only? Do they really know OOP? Isn't it supposed to be CI_Migrator and CI_Migration? The implication of this strange design is that restriction. If a class extends CI_Migration, its instance is considered a migration object. If an object is the instance of CI_Migration itself, it's considered the migrator object. Solution: when extending CI_Migration, copy-and-paste (ARGH!!) the whole constructor code because you can't use parent::__construct() (fixed in CI 3) Oh by the way, the Migration won't work perfectly with PDO driver because the PDO driver don't implement the drop table functionality (again, fixed only in CI 3).