Excellent post, and thank you for the explanation. I now understand better how the 80-20 rules applies in the case of a framework the size and complexity of Cake.
On Jun 3, 10:43 am, jperras <[email protected]> wrote: > (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 > tickethttps://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 onhttp://thechaw.com/cakephp/source/branches/1.3to 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 -~----------~----~----~----~------~----~------~--~---
