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 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 fu
