Kace,

I rarely reply to threads on this list since it is more user to user support but you got my attention here, with what seems to be a blatant attack on the project and the developers I have working with me.

How many times have you sent an email to this list in that "month" that your where "studying" Cake, asking how to do something?

I only see one email which happens to be sent on the same day you joined the group, and that is not a question but more of a statement saying that we have a flawed routing system.

Or have you stopped by the IRC channel looking for help?
Maybe even opened a ticket on our trac site stating that something is not clear in the documentation.

I will ask you another question now "oh god of coding".
What is more of a contradiction to the mantra of specifying everything once as you put it.
Adding prefixes to all method names, or writing one route to do what you need?

You ask why we do not do things like others, my answer is we are not like others, as is obvious with the way we have taken our code.
Adding prefixes to methods is nothing but redundancy that is not needed, nor will it ever be added. You stumbled upon a reserved word in php and therefore need a workaround, why should we add prefixes to all methods for these few words in php?

Cake is for people who are willing to learn and use the conventions we have wrote for it, simplicity is the key.


--
/**
* @author Larry E. Masters
* @var string $userName
* @param string $realName
* @returns string aka PhpNut
* @access  public
*/


On 5/30/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:

To all who responded:

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.

>Strategy?  That's a pretty weighty word for something so minor,
>There's nothing in this situation that needs to be documented.  If you
>know how to use PHP, you know what the reserved words are.  If you know
>how to use Cake, you know how to write a route to get around that.

If you cannot rationally accept there are things that need fixing in
this software, how can you ever progress?

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.

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

Reply via email to