My biggest request: Think outside the blog tutorial!! A lot of the supporting components work great in the context of a very simple, one controller for one model with 4 actions for CRUD setup, but become impractical or impossible to use outside that. The ACL component is probably the biggest offender of this.
So many people have problems with ACL because none of the built-in ACL schemes actually work in the real world. Also the query load is immense - why can't the ACL component pull down an entire tree branch in one query (you use MPTT, so this is pretty easy), then post-process it instead of running a query for every node? Once your tree gets to be of any real size, your application gets crippled under dozens (if not hundreds) of ACL queries. In a large application my company just built, we had to roll our own ACL component for role based permissions because the ACL component simply couldn't do it. We pull down the permissions a branch at a time, and cache them per role. There may be up to 15 ACL checks done in a single action (with full CRUD). If we were to use the built-in ACL check method, we'd be running 15 x 4 checks (one CRUD item at a time). Multiply THAT by a query for every node it has to go down and you can quickly see how this gets out of control. You could say this is way outside the scope of what the ACL component was intended to do, and that's totally fair. My argument is that the ACL component simply doesn't work in any real world scenarios and as such causes an immense amount of grief for people trying to learn how to leverage it in their own applications. I see very confused people post on here every day about ACL and most times, unless they're willing to roll their own ACL component, they're stuck. You'd almost be better off without it. The ORM has issues with being tailored to the blog tutorial as well. Another big issue people seem to have is with HABTM relationships and the inability to direct Cake's use of joins. Once you're forced to fall back to hand-written queries, you lose all the useful callbacks. There must be some middle ground here - even if it means writing your queries in a way Cake can parse and understand. Beyond those sorts of things, Cake remains my framework of choice. All in all, it is EXTREMELY flexible and consistently saves me months of development time. Any issues I can bring up could be considered minor gripes when compared to what Cake DOES get you. Cheers and thanks for your hard work and continued dedication to this project. This is a huge service to PHP developers everywhere. Don't let the whiners get to you ;) - James On May 7, 6:29 pm, Nate <[email protected]> wrote: > Well, maybe hate's a strong word. Let's say, what do you like the > least? Kind of an odd question, I know, but since we've kick-started > development of a new version, I'd like to know what the most > frustrating things with the framework are, even if they're things we > can't fix right away. > > I'll get us started: PHP 4 support. > > Who's next? TIA for the input. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
