I am puzzled by the dispatcher strategy that maps URL directly into
function names.

e.g. http://mycakeapp/control1/action1
       maps into a direct method call on action1 of class control1

This means that many function names that cannot be overloaded in
PHP cannot be used as action names.

e.g. an action "list" mapping to a method "list" is not possible
because "list" cannot be used as a method name

I suppose you can create aliases to circumvent this problem but it
seems
a contradiction to the mantra of specifying everything once.

Other frameworks solve this problem by mapping "action1" into a
function name "action_action1" which is clearer and is valid for any
word.

It also makes it easier when reading the source code to pick out
which methods are invokable as an action, and which methods are
for internal use.

Any strategy that works sometimes and not sometimes is fundamentally
flawed.  It's not a minor inconvenience, because it creates a situation
where the undesirable behaviour need to be explicitly documented.

And as far as I can see, no one has bothered to document it.  Is that
why
the mailing list is full of people complaining how difficult cake is to

understand???

Have you invesigated what you would need to do to use the url
"/controller/list" ..?

Writing one line in the routes file means that you DON'T need to write
action_ in front of every method ( using the suggestion above ). It can
quickly become tiresome writing things that you don't need to ;).

Cheers,

Count how many people have trouble and then comeback saying "I  
figured it out"
or "wow, this is neat" or as pat recently said "i may be getting a  
hang of this"
and you will find that there are many people enjoying Cake.

@All: just goes to show you that you can't make everybody happy *and*
develop good software.  If you want to go over to the land of flowers
and butterflies where everyone is happy all the time, and all
development happens be group consensus, go use the Zend Crapwork.

@Kace:
You can't always get what you want.
No you can't always get what you want.
You can't always get what you want.
But if you try sometimes,
well you might just find,
you get what you neeeeed!!
Ahhh yeah!

It is not true I don't understand MVC.  In fact I have been using MVC
as the
basis of my own software development for past 5 years, and I have coded
in
many programing languages from Java to Python.

So I do understand what frameworks are for.  Please stop projecting
your
own psychoanalytic interpretations onto someone else.

I come to Cake to find a well thought out php MVC frameworks
out of so many bad versions.

A good framework removes most of the quirks and gotchas from the
environment, so that application writers can focus on the meat of the
apps.  That is why frameworks take care of caching, sanitising inputs,
database handling, sessions etc, and hiding the PHP dependencies
in version and underlying libraries.

A framework is not just a library, because a framework has a default
execution path, which means it is a fully runable application.
Plugging
in the application-specific parts turns it into a real app.

My original perception of Cake was that the developers seem to have
deeper understanding of what MVC frameworks should and can do,
and also a good understanding of enterprise application patterns.
That I hope resulted in codes that are more systematic, orthogonal,
and elegant.

It took a month of experimentation using bad documentation and
tutorials that don't work to figure out what I now understand: cake
is not as elegant as it could have been.  The default execution
path strategies are prone to be broken without warning, e.g.
in my case, if you try to create an action called "list" in a
controller.

There is definitely something big and nasty that needs to be fixed, or
documented, or preferably both.  Unless cake is not meant to be used by

serious developers, in which case I rest my case.

Now, I will grant you that there are places where Cake could use
improvement, but this is not it.

Also, you'll have to excuse me if I have a hard time believing that you
have "experience" applying principles like MVC and convention over
configuration, since thus far you've raised most of the same objections
that we see on this list from n00bs on a regular basis.

I definitely do not intend to use Cake now that I see how inflated the
developer's ego is, that they cannot take any criticism of their
application.

What I brought up in this forum is to bring up my experience
encountering
an aberration in the framework, and all I get in return are
(1) denial (2) personal attack.

I have not attacked anyone, only the architectural design decision
which
I found to be less than orthogonal.  Those who take offence have
inferred their own proximity to the issue and inflicted
it upon themselves.

I don't know which developer made the decision to tie the name of an
action to the name of a method as a default execution path.  This is
not
safe nor universally workable.  But I did not attack him or her, only
the
strategy itself.

Whether or not anyone agrees with me, there is no denying that
such a decision has made the framework less than robust, and
requires additional code in route construction and additional
documentation to point this out to new developers.

My email raised this and nothing more.  Everything else
coming from you are overreactions because you cannot
separate the programmer's ego from his project.

Pulling out your resume to see who's balls are bigger?  How
terribly immature.

So, before I sign off from this cesspool, let me just draw
your attention to everything mentioned on Cake website's
frontpage and let you know that my experience has shown
exactly the opposite.

-- "Active Friendly community" -- nope, not what I have seen

-- "Extremely simple" -- just a few gotchas that nobody bother to
document,
  because you can sure figure out for yourself.  If not, you must be
insulted.

-- "Rapid development" -- if this is so, how come until now there isn't
any major
   non-toy application like blog, albums, ecommerce, CMS created yet in
   the forge?  

-- "No configuration" -- far from it

I am far from even 5 years of PHP development but anyway the subject of
this topic is also far from the content.
I just want to answer to kaceong's last points on this group and point
out that they're, well "fundamentally flawed".

"Active Friendly community" - now that comes with a price and that's
usually "a friendly approach" mind you.

"Extremely simple" - true, Cake is not as simple as asking a question.
But darn close. And asking usually implies not trying to discredit
anyone for their hard work.

"Rapid development" - 1.0 stable was relased May 2'nd so one month for
a huge and serious app would be in the "Lightning Fast Development"
area. Cake just goes for "Rapid".

"No configuration" - well the truth is that if you go with the standard
install there's none. But as we're developers with habits here each one
of us has his own setup more or less.

As for your comments about the documentation, well for the amount of
time CakePHP has been available, as well as the small size of the core
developers and documenters, I'm surprised it's so well documented at
all! Sure there are gaps but these are constantly being filled as they
are found. Besides what some of us believe, the team are actually only
human and therefore can only do so much, so well, in a given time.

For me, CakePHP is one of those things, like your favourite song, you
wish you were the one who had written it. Serious respect goes out to
the team.

To John, thanks for the first clear-headed response.  Yes everyone
should do whatever he or she prefers, and not try to convince anyone
else.  It was my mistake to think I could discuss a design issue
rationally with fanboys.

To Phpnut, I don't need to prove there is a flaw -- I just call it as
I saw it.  A textbook hello-world app does not work when the action
name was called "list", but works with another name "lists".
Whose fault?  Perhaps PHP.  But since the list of reserved function
names in PHP is dependent on version and installed modules, this
is a poor way to spec out a default behaviour for a framework that
might have to support multiple hosting environment.

Mathematically one counter-example is all it takes to "disprove"
a framework.

I already said I don't want a pissing contest, and you still persist
in doing so.  For the record, I said I have 5 years of coding MVC,
not 5 years of coding.  I started coding at 13 and I am 43 years
now, so that's 30 years of IT experience beginning with PDP-11.
I won't stop pulling out my dicks when I need to since I do know
what I am talking about.

Originally I have prepared a list of 25 design issues to raise in this
forum, together with my own source code changes.  But now it
is clear to me how resistant to criticism the cakesters are, so I
won't be bothering.

For those who are watching on the side and who likes Cake,
I say more power to you.  My only interest is to study the
framework and learn about it -- a framework that started with
so much promise and accolade, I was not prepared for the
denial attitudes.  To be honest the quality of source code is
not bad, which is why it is a big shame.

This is my last post and the Marie Antoinettes in this forum
can continuing telling people to eat cake, but in my opinion
a little humility and reality check is sorely needed for the cake
community to move ahead.  A community that does not
allow critics to exist will never see the truth in the
emperor's new clothes.

-"Mathematically one counter-example is all it takes to "disprove" a  
framework."
but the point is that your example does not work because there is an  
optional route you can use. Again, why prefix everything when there  
are few reserved words?

In any case, we have an RFC procedure on https://trac.cakephp.org  
that is reserved for design discussions. Its pretty simple, you  
submit a ticket marked RFC and someone replies to it. The google  
group is not where development takes place. BTW, We are working on  
2.0 which reworks some of 1.0 and adds much more. Constructive  
criticism is welcome, but the approach is as important as the  
content. Do not tell people who work extremely hard and have spent a  
tremendous amount of time thinking about the design that they are  
flawed, when you yourself just joined the list the day of your first  
post and the time you spent inspecting the framework is only a week.  
It will not get you very far.

If you've been using PHP long enough to develop a few sites/apps
*without* cakePHP, you should have come across the lovely list() [
http://php.net/list ] function which will take enumerated values from
an array and place them into variables for you. Even in traditional
development without cakePHP, you would never create your own list()
function since it already exists. This is perhaps a flaw of PHP because
of the lack of namespaces for the core functions, but it also adds to
PHP's ease of use.

Cake is not wrong for this, it's something you just shouldn't do in PHP
even without a framework. Most PHP developers would know this and would
refrain, but clearly you don't have the experience; which is fine, but
you went about your original message the wrong way.

Just because you don't understand both the language and the framework
doesn't mean the system is flawed. Obviously nothing is perfect, and
yes both Cake and PHP have their flaws, but by understanding your
environment you can walk around most of these problems. It's not a big
deal to write a specific route for yourself, and it's more of a deal to
require every other cakePHP developer to start putting something like
"action_" in front of every single one of their action methods. The
issue you have is not a design flaw with Cake because the majority of
developers are not affected, and the ones who are have a very simple
configuration available to resolve the problem.