Re: CakePHP 3.0 autocomplete

[heavyKevy]

I got the Autocomplete widget to work with the following:

Same autocomplete widget file as you but different code in controller and 
view file:
Controller:
public $helpers = [
'Form' => [
'widgets' => [
'autocomplete' => ['App\View\Widget\Autocomplete']
]
]
];

add.ctp:
Html->css('jquery-ui.theme.css');
echo $this->Html->script('jquery',['block'=>true]);
echo $this->Html->script('jquery-ui',['block'=>true]);
$this->Html->scriptStart(['block'=>true,'safe'=>false]);
?>


Html->scriptEnd();
// Using a classname.
$this->Form->addWidget(
'autocomplete',
['App\View\Widget\Autocomplete']
);
?>

Form->create($purchase,['templates'=>['autocomplete' => ''],

'onsubmit'=>'return validateForm()']); ?>


Form->input('sales_person', ['type' => 
'autocomplete','label'=>'Sales 
Person','id'=>'sales_person','required'=>true]);
  
Form->button(__('Submit')); ?>
Form->end(); ?>



I eliminated all of the items not necessary for the example, so there are 
likely errors in there, but it should give you the gist of what is needed 
for the autocomplete to work.

Regards,
--Kevin

On Tuesday, September 30, 2014 7:33:24 PM UTC+7, Radharadhya Dasa wrote:
>
> Hi, 
>
> I am trying to make an autocomplete input work on Cake 3.0
>
> The current 3.0 cookbook gives a code example here : 
> http://book.cakephp.org/3.0/en/core-libraries/helpers/form.html
>
> If I try it I get an error message: 
> *Fatal error*: Declaration of App\View\Widget\Autocomplete::render() must 
> be compatible with Cake\View\Widget\WidgetInterface::render(array $data, 
> Cake\View\Form\ContextInterface $context) in 
> */home/rrd/public_html/sanga/src/View/Widget/Autocomplete.php* on line 
>
> *6*If I change my render function to 
>
> *public function render(array $data, Cake\View\Form\ContextInterface 
> $context) {*
> Still I get the same error message.
>
> Any idea how to solve this?
>
> rrd
>

-- 
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 cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Re: The (bad) perception and image of CakePHP in the public

[j0n4s.h4rtm...@googlemail.com]

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  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).  
>
>

Re: The (bad) perception and image of CakePHP in the public

[Jeremy Burns : Class Outfit]

I've found the documentation pretty good on the whole, but there are two common 
issues:

1) It sometimes it lacks context. I can see the code example, but where does it 
go, what does it rely on and what does it impact?
2) It sometimes relies on an existing knowledge of the subject matter or 
something related, so it doesn't always make sense.

- Jeremy

On 1 Oct 2014, at 19:56, 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  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 approach

Re: The (bad) perception and image of CakePHP in the public

[mark_story]

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

Re: The (bad) perception and image of CakePHP in the public

[John Sposato]

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

report dispaly

[Nizeyimana Eugene]

Am using cakephp to display my report and i want to display without 
repetiton (for instance survey may have many questions and answers and its 
numbers of respondents) for each surveys, using cakephp. And if it help me 
about graphs such histogram..

Thx

-- 
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 cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Re: The (bad) perception and image of CakePHP in the public

[j0n4s.h4rtm...@googlemail.com]

So for me in 3 words, CakePHP3 is:
- Best ORM
- Awesome Book / Docs
- Super Maintainance

TLDR;

CakePHP 2 Tops:
- Book
- Community
- Linkable
- Recursive = 3 ;P
- Cake Bake and great bake looks out of the box
- CRUDv3, Scaffold
- Super maintainance cycles and fast security patches <3
- Super Stable
- Highly integrated
- Extensive unit tests
- Good FRAMEwork that makes sane suggestions for you how to implement 
stuff: Models, Behaviors, Components, Controllers, Views, Helpers, 
Templates, Callbacks.
- Great upgradability within major versions

CakePHP 2 Flops:
- Recursive = 3 ;)
- ORM
- Tightly coupled

Honestly, ex post I think I might have stayed on Cake PHP 2 for too long 
and maybe should have switched for better code and maintainability - 
because of its weak and aged ORM and rather dirty model layer and its aged 
features from PHP <= 5.3 times. The little critique I had would be that 
maybe it had been a good idea to push the old cake3 as cake3. This what we 
got today is basically 'Cake 4'. The feature/architecture jump for the ORM 
is /that/ huge.

So things have changed. Thanks to the cake core team Cake PHP 3 looks very 
very good and is already something other projects would ship as CakePHP 3.0 
Final.

So what about CakePHP 3? The tops of CakePHP 2 are still there:
- Book
- Community
- Linkable replaced by awesomesauce ORM - very elegant and probably one of 
the best in PHP world and very close to AREL.
- Cake Bake, RAD, CRUDv4
- Super maintainance cycles and fast security patches (at least I hope so 
;) 
- Super stable already (e.g. it doesn't break at all edges in common cases)
- Extensive unit tests
- Good FRAMEwork that makes sane suggestions for you how to implement 
stuff: Models, Behaviors, Components, Controllers, Views, Helpers, 
Templates, Callbacks.

What got improved over CakePHP 2:
- ORM awsomesauce
- Namespaces, recent PHP 5.4 features, aiming for PHP 5.5 in future 
releases (so that's a GOOD change as PHP is finally getting modern due to 
facebook's pressure by hiphop)
- Less coupled, more open/reusable components (a similar way rails 3 went 
IMHO)
- Very similar helper and controller APIs so migration of 50% of your app 
will be a breeze
- Cells

So for me in 3 words, CakePHP3 is:
- Best ORM
- Awesome Book / Docs
- Super Maintainance

What more can you get?

On Tuesday, September 30, 2014 10:28:32 AM UTC+2, 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 > 
>> 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 th

Re: The (bad) perception and image of CakePHP in the public

[Stefano Zoffoli]

   1. it relieves me to do the hard (and tedious) work with nice apis and
   abstraction layers that allow me to do my job better and quickly
   2. it leads me to use good standards with conventions over
   configurations that allow me to have a cleaner code that is easier to
   mantain
   3. it has a strong community that continues to mantain, test and develop
   this awesome framework to achieve new standards and functionality (ie. psr,
   composer...)



--
 Stefano Zoffoli
*Resp. Sviluppo Software*
347 8180258

*Librasoft Snc*
www.LibrasoftSnc.it 
www.ProgettoKuma.it 
0543 424612

2014-10-01 10:40 GMT+02:00 stork :

> > why you think CakePHP is a cool or productive framework to work with?
>
> Cool:
> 1. community
> 2. lightweight, with very few dependencies
> 3. easy way to contribute to the sources and docs
>
> Productive:
> 1. core code moving ahead (enhancements and adoptions of the new PHP
> features) wisely, very few deprecated/abandoned things over time
> 2. coding standards and conventions, it is easy to jump into code written
> by someone else and/or collaborate on project one doesn't know in detail
> right from the start
> 3. extendability (and it is continuously getting even better)
>
> --
> 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 cake-php+unsubscr...@googlegroups.com.
> To post to this group, send email to cake-php@googlegroups.com.
> 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 cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Re: i18n problem

[Lucky1968]

UPDATE: I also have to use $array[0]['Model__i18n_translated_field'] in 
normal (not forms) view files.

On Wednesday, October 1, 2014 9:32:05 AM UTC+2, Lucky1968 wrote:
>
> Hi,
>
> I'm using i18n in my application and it seems that in certain views I can 
> use $array['translated_field'] as in other views I need to use 
> $array[0]['Model__i18n_translated_field'] to get the same information 
> coming from the same find in the same model.
>
> Can anyone tell me why this is?
>
> This is my code:
>
> MY MODEL (SettingsSite.php):
> 
> class SettingsSite extends AppModel {
>
> public $actsAs = array(
> 'Translate' => array(
> 'slogan'
> )
> );
>
> ...
>
> public function first_site() {
> return $this->find('first', array('recursive' => -1));
> }
>
> }
> 
>
> MY VIEWS:
> 
> App::import('Model', array('SettingsSite'));
> $settingsSiteObj = new SettingsSite();
> $first_site = $settingsSiteObj->first_site();
> 
>
> RESULTS:
> In (almost) all my view files within my main application and in all my 
> view files in plugins I get the results like this:
>
> array(
>   'SettingsSite' => array(
>   ...
>   'locale' => 'eng',
>   'slogan' => 'Translated Slogan'
>   )
> )
>
> But in (apparently form-) view files in my main application I get the 
> results like this:
>
> array(
>   'SettingsSite' => array(
>   ...
>   'locale' => 'eng',
>   'slogan' => ''
>   ),
>   (int) 0 => array(
>   'SettingsSite__i18n_slogan' => 'Translated Slogan'
>   )
> )
>
> As said, all the code in the view files is identical and therefor pointing 
> to the same function in the same model. And the a.m. result code is the 
> result of debug() within the models function, so IMHO, shouldn't be 
> influenced by anything else in the view file.
>
> Can someone tell me why this is?
>
> Thanx.
>
> Luc
>

-- 
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 cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Re: The (bad) perception and image of CakePHP in the public

[stork]

> why you think CakePHP is a cool or productive framework to work with?

Cool:
1. community
2. lightweight, with very few dependencies
3. easy way to contribute to the sources and docs

Productive:
1. core code moving ahead (enhancements and adoptions of the new PHP 
features) wisely, very few deprecated/abandoned things over time
2. coding standards and conventions, it is easy to jump into code written 
by someone else and/or collaborate on project one doesn't know in detail 
right from the start
3. extendability (and it is continuously getting even better)

-- 
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 cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Re: The (bad) perception and image of CakePHP in the public

[Dakota]

   
   1. Good, predictable and easy to understand documentation
   2. Incredibly friendly and welcoming community and development team
   3. Easy of use


On Tuesday, 30 September 2014 10:28:32 UTC+2, 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 > 
>> 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 
>

i18n problem

[Lucky1968]

Hi,

I'm using i18n in my application and it seems that in certain views I can 
use $array['translated_field'] as in other views I need to use 
$array[0]['Model__i18n_translated_field'] to get the same information 
coming from the same find in the same model.

Can anyone tell me why this is?

This is my code:

MY MODEL (SettingsSite.php):

class SettingsSite extends AppModel {

public $actsAs = array(
'Translate' => array(
'slogan'
)
);

...

public function first_site() {
return $this->find('first', array('recursive' => -1));
}

}


MY VIEWS:

App::import('Model', array('SettingsSite'));
$settingsSiteObj = new SettingsSite();
$first_site = $settingsSiteObj->first_site();


RESULTS:
In (almost) all my view files within my main application and in all my view 
files in plugins I get the results like this:

array(
'SettingsSite' => array(
...
'locale' => 'eng',
'slogan' => 'Translated Slogan'
)
)

But in (apparently form-) view files in my main application I get the 
results like this:

array(
'SettingsSite' => array(
...
'locale' => 'eng',
'slogan' => ''
),
(int) 0 => array(
'SettingsSite__i18n_slogan' => 'Translated Slogan'
)
)

As said, all the code in the view files is identical and therefor pointing 
to the same function in the same model. And the a.m. result code is the 
result of debug() within the models function, so IMHO, shouldn't be 
influenced by anything else in the view file.

Can someone tell me why this is?

Thanx.

Luc

-- 
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 cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.

Re: CakePHP 3.0.0-beta2 released

[José Lorenzo]

It is https://github.com/cakephp/migrations

Sorry I got it wrong when writing the release

On Wednesday, October 1, 2014 6:01:35 AM UTC+2, Dr. Tarique Sani wrote:
>
> What is the link to the Migrations plugin?
>
> T
>
> On Tue, Sep 30, 2014 at 4:44 AM, Reuben  wrote:
>
>> Super excited for separate packages, and using components inside other 
>> applications.
>>
>>
>> On Sunday, 28 September 2014 23:49:02 UTC+10, José Lorenzo wrote:
>>>
>>> The CakePHP core team is proud to announce the second beta release for 
>>> CakePHP 
>>> 3.0.0 .
>>> It's been a month since our first beta release, and we are excited by 
>>> the big welcome the community has given to the new version. All the 
>>> positive feedback and help has been a great motivation for the core team to 
>>> work harder on improving the developer experience for 3.0.
>>>
>>> This will be the last beta release for 3.0, this means that the API is 
>>> already stabilizing and we're mostly focusing on polishing the current 
>>> features, performance optimizations, documentation and quickly solving any 
>>> issues reported in Github.
>>>
>>> We've had a very busy month implementing a few missing features we had 
>>> in our roadmap and upgrading some of the popular plugins for CakePHP.
>>>
>>> Below the list of new features and changes that made it into 3.0.0-beta2:
>>> DebugKit 
>>>
>>> Debugging CakePHP 3.0 applications is even better. The new DebugKit is 
>>> easier to install, faster and looks gorgeous.
>>>
>>> DebugKit is a application toolbar that collects useful statistics about 
>>> your code such as time and memory, executed queries, log messages and view 
>>> variables. To install Debugkit just use
>>>
>>> composer require cakephp/debug_kit "3.0.*-dev"
>>>
>>> And add this line to your bootstrap.php file:
>>>
>>> Plugin::load('DebugKit', ['bootstrap' => true]);
>>>
>>> If you install a new application using the app skeleton 
>>> , DebugKit will be automatically 
>>> installed for you.
>>> Database Migrations 
>>>
>>> Migrations  is now an official 
>>> CakePHP plugin. It wraps the excellent Phinx  
>>> library into a CakePHP shell to avoid repeating configuration strings and 
>>> add some of the cake experience. A database migration generated by this 
>>> plugin would look like:
>>>
>>> >> AbstractMigration {
>>> /** * Change. */
>>> public function change() {
>>> // create the table
>>> $table = $this->table('users');
>>> $table->addColumn('id', 'integer')
>>> ->addColumn('username', 'string')
>>> ->addColumn('password', 'string')
>>> ->addColumn('created', 'datetime')
>>> ->create();
>>> }
>>>
>>> Migrations are reversible. This means that with the same code you can 
>>> create or rollback the changes done to the database schema.
>>>
>>> To install the Migrations plugins run:
>>>
>>> composer require cakephp/migrations "dev-master"
>>>
>>> And add this line to your bootstrap.php file:
>>>
>>> Plugin::load('Migrations');
>>>
>>> New Logger interface 
>>>
>>> CakePHP has adopted the PSR-3 recommendation for loggers. Now all log 
>>> engines implement the Prs\Log\LoggerInterface interface. This means 
>>> that the entire logging system can easily be replaced by other 
>>> implementations, such as the popular Monolog library 
>>> .
>>> Integration Tests and Data Integrity 
>>>
>>> Testing controllers has always been problematic. While 
>>> ControllerTestCase solved some of the problems, we identified this 
>>> class as a source of problems and confusion among our users. We decided to 
>>> implement the new IntegrationTestCase class as a way totest all aspects 
>>> of an HTTP request in your application without much mocking being involved. 
>>> This should help you improve code quality and ensure that your application 
>>> and routes are working as expected.
>>>
>>> We also made the fixtures system better, allowing developers to define 
>>> and work with foreign key constraints in their database. The fixtures 
>>> system will now correctly load all data and enable constraints right before 
>>> your test code is executed.
>>> New Bake templates 
>>>
>>> With the date for a stable release getting closer and closer we decided 
>>> to give a new look to default baked applications. Hopefully the new look 
>>> will feel fresher, more modern, and easier to work with.
>>> Separate packages 
>>>
>>> We've seen an increasing interest in using the new ORM outside the 
>>> framework or within older CakePHP applications. One of our goals since the 
>>> start has been making this possible. We have already begun the work to 
>>> split the framework into various standalone components that can be reused 
>>> and installed with composer. While the ORM has not yet been extracted into 
>>> its own r

Re: i18n base language and database fields

[Dr. Tarique Sani]

On Wed, Oct 1, 2014 at 12:07 PM, Lucky1968  wrote:
>
>
> I suggest you use your solution c), so make everything in English by __()
>  and do the translation when your application is ready by extracting the
> .pot files. Extremely easy.
>

Yep! +1 to the above suggestion

./Console/cake i18n extract

Will create the .po file for you

T

-- 
=
Hire a CakePHP dev team : http://sanisoft.com
=

-- 
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 cake-php+unsubscr...@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.