Thanks for this, I'm glad this a topic in the forefront of your minds
while developing Cake. I like the product very much, but have seen good
intentions turn into bloat many times over in my 25 years in the
software industry :-)
Just a couple followup topics on this:
1. It would be great to have a "guide" that discusses the
current/future "magic" in cake. For example, what is the special
significance of primary key fields and having them be named a certain
way? I think several things happen "behind the scenes" in the tool
regarding id fields, but I have not been able to piece together a
complete "picture" of this from the manuals, the api, and the
tutorials.
I would love to contribute to this actually. I can totally imagine a
guide called "Cake Magic" that focuses on how these helpful
functionalitites "come together" if you follow certain rules and
conventions.
To me, this information is useful in its own right and could be kept
separate from the documentation on the basic MVC/Front End Controller
docs which describe the basic page generation design of Cake
2. The comments here about being able to chose how much magic you
use/get by default: I'm not sure I agree 100% that it's that easy to
not get the magic by default. I think the product is increasingly
geared toward getting the magic and then having to know how to turn
that off or avoid it if you don't want it.
For example, in an earlier post I was asking about how to use Cake's DB
access without descending from AppModel. I cited some cases where
AppModel didn't seem to be such a good fit, such as in cases where you
don't know in advance the table or tables a model would be working
with, or models that need to create tables on the fly.
The answer I got was basically the best way to do db accesss was to use
AppModel. Some suggested using the query() and execute() methods as a
way to get "direct" data access. This sounds good, but the fact remains
that in order to do this you must create a model that descends from App
Model, and is related to some existing table already in the database,
which seems clumsy in some cases. So to me there is an assumption that
you *will* follow Cake's assumptions about tables, etc, if you want to
get at database access at all.
Also, regarding being able to still use the old HtmlHelper, if I use
some of the HtmlHelper functions to generate html controls, I get
messages that the functions are deprecated and FormsHelper should be
used instead. And when I use FormsHelper (I realize the docs are not
yet done for it) the default parameteres for functions like input() and
create() consider/assume quite a few things that are not made clear
anywhere... In short, I feel like we are (or will be, when 1.2 becomes
production) being strongly encouraged to use FormsHelper with its
default behaviors, which include a fair amount of "magic", which is not
published.
These are not complaints, just observations that make me feel that
there are some unspoken assumptions (another great document suggestion)
about the type of applications Cake is "best for" (I know you can
"disable" some of the behaviour, but again that's not the default so
you have to take the stance that Cake is "intended" to be used in its
default way)
I have offered in another thread to help with docs but am a bit unsure
about who to contact regarding this.
Thanks
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
