Actually mark_story most of the documentation is really really damn good. I 
am really not the most advanced coder and I can get around with the docs 
and API quite well. So maybe it has to do with laziness as well. But as you 
asked, what I never really understood is how cakes errors and exceptions 
work and how to build upon them and customize and extend them. Same goes 
for views but I did not require them as of yet. That aside I really did not 
find anything "lacking" especially because cake2 is really not too complex. 
For Cake3 I can see that there should maybe be a more advanced chapter on 
the ORM (similar to what the advanced workshop offered but with even more 
depth) because it is really a strong ORM but at the same time it is not as 
easy as a simple contain and then array traversal in afterfind or recursive 
3 or whatnot. But I have to say it again, the docs are quite good and the 
docs and the tight integration (e.g.a real FRAMEwork and not a bunch of 
zend libs and java-land-like stuff) were the reason I chose cake1.2 back 
then.

On Wednesday, October 1, 2014 8:56:56 PM UTC+2, mark_story wrote:
>
> As someone who writes a pile of documentation, what kinds of advanced 
> things have you found lacking? I've found it challenging to add more 
> advanced examples as they often end up being very situational and we'll 
> always have some use case that doesn't have a full example. I'm interested 
> in what you've found lacking, perhaps there are generic enough examples 
> that can be added.
>
> -Mark
>
> On Wednesday, 1 October 2014 11:42:59 UTC-4, John Sposato wrote:
>>
>> I think it's interesting that some people say the docs are terrible and 
>> others list documentation as a reason why it's cool or productive.
>>
>> If you're build a blog application that will only do simple relationships 
>> and not a lot of complex things, the documentation is great.  However, we 
>> typically don't do things that simple.  We find the documentation lacking 
>> for more advanced users.  And, since we're always pressed for time, 
>> figuring it out isn't always a viable solution. 
>>
>> If you want people to come to your framework, the #1 thing should be 
>> documentation. CakePHP 2.x is stable and works well so maybe some effort 
>> could be redirected into adding to/improving the documentation?
>>
>> On Tuesday, September 30, 2014 4:28:32 AM UTC-4, José Lorenzo wrote:
>>>
>>> Before giving my own view into this problem, you you guys list the 
>>> reasons why you think CakePHP is a cool or productive framework to work 
>>> with? Just give me 3 reasons, no comparisons with other frameworks
>>>
>>> On Tuesday, September 30, 2014 6:24:30 AM UTC+2, Jeremy Burns wrote:
>>>>
>>>> This is so true. I’m a huge fan of Cake but we do feel like the 
>>>> whipping boys sometimes. I recently hired someone into a project and the 
>>>> first thing he tried to do was change the framework for a whole bunch of 
>>>> vague reasons like ‘Laravel is just so much better’.
>>>>
>>>> Perhaps someone can devise some simple benchmarking challenges that the 
>>>> guardians of the various frameworks can take up themselves and then 
>>>> compare 
>>>> the actual results, rather than letting a random person do it out of the 
>>>> box. A competition, if you will. So, for example, write a thousand records 
>>>> to a database, read them back, perform some function and render them to 
>>>> screen. Yes, yes, I know there would need to be some element of a level 
>>>> playing field with server spec and the like, but it could be done. Then 
>>>> each framework can show it’s own best efforts and - importantly - will 
>>>> have 
>>>> no excuses about not understanding the framework or setting it up 
>>>> correctly.
>>>>
>>>> I haven’t had a ‘job’ for the past six years, but on the odd time that 
>>>> I decide a regular income would be nice I rarely - if ever - see CakePHP 
>>>> as 
>>>> a requirement. It’s always Symfony, Zend, Drupal, Code Ingniter, sometimes 
>>>> Laravel, sometimes ROR and sometimes something else. That’s awkward and I 
>>>> just can’t help wondering if I am swimming against a tide. Perhaps 
>>>> everyone 
>>>> else is right and I am wrong? TBH, I’m not clever enough to be able to 
>>>> explain why Cake is the right choice compared to others; some help there 
>>>> would be cool.
>>>>
>>>> On 30 Sep 2014, at 00:43, Reuben <[email protected]> wrote:
>>>>
>>>> My apologies, dereuromark, for the incorrect spelling of your handle.
>>>>
>>>> On Tuesday, 30 September 2014 09:40:31 UTC+10, Reuben wrote:
>>>>>
>>>>> The few times that I've seen CakePHP compared to other PHP frameworks 
>>>>> is in performance tests, and it never looks pretty.  Usually the test is 
>>>>> a 
>>>>> very simple Hello World test, or an action that reads/writes a bunch of 
>>>>> records to the database.  Not really real work tests, and no effort to 
>>>>> configure the application to make sure it's doing the best that it can 
>>>>> (i.e. appropriate cache options, etc).  
>>>>>
>>>>> There have been a few articles written on CakePHP and performance, and 
>>>>> all the stuff you can do before complaining about the framework itself.
>>>>>
>>>>> Unfortunately, when people are comparing PHP frameworks, they just 
>>>>> look for that performance index, and don't take too much notice of the 
>>>>> merits of the performance test taken.
>>>>>
>>>>> My perception is that at last check, there might be room for 
>>>>> improvement in the event model, but I don't do all the other things that 
>>>>> can be done to get better performance out of CakePHP, before going there, 
>>>>> so it's never been an issue for me.  I also understand that start up 
>>>>> times 
>>>>> have been improved with CakePHP 3, and the routing configuration required.
>>>>>
>>>>> Of course, CakePHP is more than just performance of the framework. 
>>>>>  The documentation is great, the community is great and the core 
>>>>> development team are very approachable, via groups, irc and github 
>>>>> issues. 
>>>>> And the code itself, should you need to look at it, is very readable.  
>>>>> The 
>>>>> only part that makes my brain hurt a little is the event system, 
>>>>> especially 
>>>>> when trying to work out, when this event is fired, what is listening for 
>>>>> it 
>>>>> in the CakePHP core.  
>>>>>
>>>>> Maybe there could be some articles written about the CakePHP core, to 
>>>>> make TheBakery a little more attractive to read. I'm more likely to read 
>>>>> CakePHP articles from Mark Story, AD7six or deuromark than peruse the 1 
>>>>> or 
>>>>> 2 paragraph articles on TheBakery.
>>>>>
>>>>> Regards
>>>>> Reuben Helms
>>>>>
>>>>> On Tuesday, 30 September 2014 07:15:54 UTC+10, Florian Krämer wrote:
>>>>>>
>>>>>> In the official CakePHP Facebook group Yanuar Nurcahyo asked about 
>>>>>> opinions on that link 
>>>>>> http://www.quora.com/Why-isnt-Cakephp-popular-despite-being-one-of-the-earliest-php-framework-to-be-written
>>>>>>
>>>>>> I'll quote my own comment I've added to that posting:
>>>>>>
>>>>>> I'm a little shocked about the wrong information people spreading 
>>>>>>> there as well as the amount of false information. Especially the one 
>>>>>>> that 
>>>>>>> got 4 up-votes. Most of the answers there read like FUD or written by 
>>>>>>> people who can't or won't read documentation. Also I really don't get 
>>>>>>> why 
>>>>>>> people always "need" bleeding edge php support. There is no urgent 
>>>>>>> need or do you migrate you app / server to a new php version just 
>>>>>>> because 
>>>>>>> it's cool? The only problem that CakePHP has is an image problem.
>>>>>>
>>>>>>
>>>>>> What I would like to discuss in this thread is reasons and solution 
>>>>>> to them. Why has CakePHP such a negative perception? The thing that 
>>>>>> bothers 
>>>>>> me personally the most is why the *uck do people say it has a bad 
>>>>>> documentation? Seriously, I don't get it. Can't they find the 
>>>>>> documentation? Can't they use it? Or is it really just FUD by some 
>>>>>> <random-framework> fanboys?
>>>>>>
>>>>>> The "stone age php version" isn't a very valid argument IMHO. Yes, I 
>>>>>> agree, CakePHP felt behind other frameworks for at least ~2 years and 
>>>>>> I've 
>>>>>> missed the namespace support more than one time. But that was really the 
>>>>>> only language feature I was really missing. Everything else is sugar on 
>>>>>> top 
>>>>>> of the cake. I don't know if other people update their servers and apps 
>>>>>> for 
>>>>>> fun and if they do the required testing for free for their clients...but 
>>>>>> well, looks like some guys out there have more a cowboy-coder attitude 
>>>>>> than 
>>>>>> a professional one.
>>>>>>
>>>>>> Also I don't get why people complain about the architecture of 
>>>>>> CakePHP, yes it is different, yes it gives you everything out of the box 
>>>>>> and isn't a package made of 100 loose libs and then glued together. This 
>>>>>> is 
>>>>>> IMHO actually an advantage and makes it easy to get started with it. And 
>>>>>> seriously, how often do you change the ORM stack of <random-framework> 
>>>>>> in 
>>>>>> reality? And on top of that, CakePHP 3.0, as far as I can tell, is more 
>>>>>> decoupled than 2.0 was. For example the face pattern in Laravel is, as 
>>>>>> far 
>>>>>> as I've worked with it and understood it, just one way you can use for 
>>>>>> dependency injection. The face seems to works like a proxy. I might be 
>>>>>> wrong, I haven't spent much time with it yet. SF2 is using a container 
>>>>>> object to deal with the dependencies. However, my point here is other 
>>>>>> frameworks *appear* to be more fancy and by this attract people who 
>>>>>> are looking for fancy things, "interesting" design patterns and 
>>>>>> architecture. Which brings us back to the cowboy-coder attitude. 
>>>>>> Something 
>>>>>> doesn't has to be fancy to just work.
>>>>>>
>>>>>> I know that for example Symfony gets a lot attention and exposure 
>>>>>> through having virtually one domain per component of their framework and 
>>>>>> a 
>>>>>> nice design for these sites and for whatever reason Symfony manages it 
>>>>>> somehow to get massive funding. Creating all these pages and a fancy 
>>>>>> design 
>>>>>> takes time and money. So I don't think doing something similar would be 
>>>>>> an 
>>>>>> option for CakePHP. Honestly I have no ideas what could be done to help 
>>>>>> making CakePHP look better (and stop these silly guys from spreading 
>>>>>> FUD). 
>>>>>> I would not mind all their critics at all if they would bring valid and 
>>>>>> detailed arguments. But everybody complaining about CakePHP is just 
>>>>>> repeating other peoples FUD about a bad documentation and not exactly 
>>>>>> mentioning what is wrong with the architecture. Going into a discussion 
>>>>>> is 
>>>>>> like going into a fight without a weapon. But well, the problem here is 
>>>>>> nobody fights these false "arguments". :(
>>>>>>
>>>>>> I personally don't mind using Symfony2 or Laravel, they're good 
>>>>>> frameworks as well, but I don't think that CakePHP 3.0 has to hide in 
>>>>>> any 
>>>>>> aspect, nor had Cake2 when it was new. But CakePHP has a completely 
>>>>>> different philosophy than SF2 and Laravel, obviously one that people are 
>>>>>> not used to.
>>>>>>
>>>>>> So, has anyone constructive critics about that? Maybe others here 
>>>>>> don't even think CakePHP has a problem with it's perception?
>>>>>>
>>>>>
>>>> -- 
>>>> Like Us on FaceBook https://www.facebook.com/CakePHP
>>>> Find us on Twitter http://twitter.com/CakePHP
>>>>
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "CakePHP" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at http://groups.google.com/group/cake-php.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>

-- 
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP

--- 
You received this message because you are subscribed to the Google Groups 
"CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Reply via email to