(for context, please read the comments for ticket #5145: https://trac.cakephp.org/ticket/5145 . I chose continue this discussion in the google group because it is a more appropriate venue for this type of discourse).
First, let me state that neither myself or *anyone* on the CakePHP core team gets their jollies from closing tickets as 'wontfix' or 'invalid'. We all appreciate the time & effort that is spent in writing a ticket, and are grateful that people are attempting to make CakePHP a better framework. Alright, I'm going to take the time to explain the reasoning behind the 'wontfix' tag that was attributed to ticket https://trac.cakephp.org/ticket/5145 and perhaps offer some insight in the thought processes that go on behind the scenes that are not usually explained, for the simple reason that writing a small novella for each ticket would consume all the free time that any of us has. First, you must note that CakePHP is an ''opinionated'' framework; we enforce certain conventions and (what we consider to be) best practices. This also translates to any code that is included in the core; if we believe that certain enhancements/features would go against accepted best-practices of development, then it has no place in the official codebase. Being conscious of the limitations of the real world, however, we have endeavoured to allow users of the framework to customize & extend the base functionality to accommodate a wide variety of edge case uses, an example of which is the topic of this ticket: Validation rules. The rules that are provided in the core are present for one of two reasons: 1) the rule is quite common and used in many different applications (e.g. notEmpty, numeric) or 2) the implementation of the rule is quite complex, and we feel it best to provide that functionality so that people need not re-invent the wheel (e.g. credit cards, date and time). The alphanumeric+ whitespace +whitelist_of_valid_characters rule which you have proposed does not fall within either of the above two categories. It is not a rule which many people require, simply because if you are allowing non alphanumeric characters, you need to either provide a whitelist or a blacklist of additional characters. Neither of these options is maintainable in the long-term; you will be eternally adding characters to your (white|black)list to comply with varying & changing requirements from your application. However, I do understand that the real-world sometimes does not coincide with the ivory tower that comprises best practices of software design & implementation patterns. This is where the extensibility of the framework comes into play. The above validation rule that you both desire can be very easily implemented in a variety of places: 1) in a model, for domain-specific validation that need not be available to the rest of your application. 2) at the AppModel level, so that all your models in a given application may use it. 3) In a behavior, so that you can pick & choose which models will have the custom validation rules available to them. In addition, this also allows you to make the rules portable; you could even package it up in a plugin along with some test cases, thus utilizing the full extent of CakePHP's extensibility. Furthermore, every line of code that is added to the CakePHP codebase is a line of code that the core team needs to maintain. What might seem like a simple validation rule addition actually encompasses the validation rule itself, a new test case with at least a dozen new assertions, possible modification of bake templates for models to include the new validation rule, integration tests for the new validation rule and its interaction with the FormHelper, in addition to whatever new functionality gets added in future versions. As a result, what seems like a simple addition of a few lines of code snowballs into several hundred lines and countless hours of work. Thus you can imagine why we shy away from adding new 'features' that introduce infinitesimally new functionality, especially when such functionality is actually best implemented with your own application logic in mind. This is not to say that we never plan on adding new and awesome things to CakePHP; you need only visit the development branch for 1.3 on http://thechaw.com/cakephp/source/branches/1.3 to see for yourself. Given all that I've said, however, I still realize that sometimes certain problems need dirty solutions. To this end, I've written a simple example of how you would create an alphanumeric +whitelist_of_valid_characters rule: // in either your app_model.php or a model class public function alnumWhitelist($data, $whitelist = array()) { $data = array_values($data); $check = $data[0]; $whitelist = implode($whitelist); $rule = "/^[\p{Ll}\p{Lm}\p{Lo}\p{Lt}\p{Lu}\p{Nd}{$whitelist}]+ $/mu"; return preg_match($rule, $check); } // in your model validation rules public $validate = array( 'name' => array( 'rule' => array('alnumWhitelist', array('\s', '\-', "\'", '\"')), 'allowEmpty' => false ), ); So please, try and remember that we're not trying to be the bad guys. The whole core team has nothing but the best intentions for CakePHP and the community behind it. When we mark tickets as invalid or wontfix, we're not trying to piss you off. Every decision has a reason, and many of them are debated extensively among the core team. Thanks, and have a pleasant day. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
