On Jan 6, 10:05 am, Robby Anderson <[EMAIL PROTECTED]> wrote:
> cake is), but doesn't help scaffolding (which is admittedly pretty
> minor). I find the attached quote interesting ('Whereas we '...try to
> live by "convention over configuration"') - when you can change so
> many other database naming conventions using configuation (and happilyThis isn't configuration in the sense that you're simply changing a setting. This isn't something that's exposed by default. You have to go out of your way to programatically change the functionality. The fact is, scaffold (and bake) can be extended in similar ways by creating templates, but again, because a central design philosophy is "convention over configuration," simply changing a setting for this kind of functionality is not something that Cake will ever support. If you want it, you're going to have to do some real work. It's still not much work (default templates are provided, which you can tweak, for example), but it's work nonetheless. > so). And sadly, some of us don't have the luxury of of changing legacy > databases to match convention and would still like to use cake and its > otherwise nifty features. :( Again, not so: you still can use all of Cake's nifty features, but bake and scaffold are *simple* tools. This simplicity is both a cause and an effect of the design decisions we've made in the framework. These tools help promote and enforce convention, and working outside of the convention *should* hurt. It *should* require extra work. That's exactly what makes working *within* the convention so simple and streamlined. Another thing that very few people realize or bother to consider is that every little pet feature has a cost: the framework runs slower, the memory footprint expands, the codebase becomes bloated. On the development team, our primary responsibility when evaluating new features is to act as filters, in order to mitigate these costs. Typically, we try to err on the side of passiveness: i.e. rather than necessarily implementing a feature, we will expose the functionality to which the feature is related, such that the framework is adequately extensible to allow users to implement the requested functionality on their own, without having to hack the core. This is not only a more efficient strategy in terms of cost, but it is a vastly more effective solution over the long term, as it enables programatic customization far beyond the narrow scope of the specific enhancement requested. It accommodates more future use cases than have even been imagined yet. Granted, it may take the few developers for which the specific enhancement is useful a few extra lines of code to achieve *their* desired result, but the end result for the development community at large is far better than it would be, had we actually implemented each enhancement as requested. Now, Robby, given your relative lack of experience, I can understand why you'd request such a feature, but the fact is, not only is this a narrow feature of limited utility, but it directly controverts one of the central design philosophies of the framework itself. I'd have to be crazy to implement it. ;-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" 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 -~----------~----~----~----~------~----~------~--~---
