Re: CakePHP future
I agree with you mark, Allot of companies are still on older php versions, the CentOS/RedHat repositories are still on 5.1.6 if I remember correctly. And I can't see them changing that any time soon. PHP 5.3 features in the framework is all good, but by doing it it will cause the framework not to work on some shared hostings anymore. And especially for companies, they don't 'just' upgrade. I want to use the 5.3 myself for my personal sites, because I like some of the new features(and gc). Personally I think it's a shame that again another framework is being made. If everyone could work together on one, that would be so much more beneficial. Although I understand that each developer has his/her own idea's on what should be done. For that reason ppl don't always get along/see eye to eye. That being said, the idea is good, php5.3 has some nice new features that could speed up/expand the core functionality, but for now, it's to soon On Sep 9, 5:20 am, mark_story mark.st...@gmail.com wrote: The standards you are referring to are most likely the PSR guidelines, and we are looking into ways that we can make CakePHP compatible with the ideas in the guidelines. I think the ability to combine different frameworks and libraries together is generally something that can already be done. There are a few pain points, and I hope to find the time to figure out how to make them less painful. Just because a framework isn't 5.3 only doesn't mean you can't use 5.3 features in your application code. -Mark On Sep 7, 5:53 am, j0n4s.h4rtm...@googlemail.com j0n4s.h4rtm...@googlemail.com wrote: two notes on this: a.) while this might not make me friends: Lithium may be able to pull of both: a.) a very microkernel framework that comes without much tools and with a loose frame (thus bad for newbies and bad programmers like me ;-p) and b.) a standard set of addons extensions plugins whatever: data sources/object mappers, filters, authenfication, access control, etc. Why do I say this? Rails 3 did this (Though the basis of Ruby implies different contraints, some very positive other rather negative) (More on that topic on the rails website under screencasts, Rails 3 Screencast Series, the screencasts show the decoupling of the frame- parts (read framework parts) and the great Arel :)). So I could very well imagen Lithium and Lithium+, though on the other side of the coin - if there will be no Lithium+ in the long run - I do not see it becoming much more popular than ZF though. b.) I do not like general OSS wars, they just consume time. Instead I want to ask a question: Afaik Lithium is committed to some php library standard definitions. Will Cake2 share those? And if that's the case: can you see combined use of both, parts of them and/or integration? p.s: While I do not like php 5.3s syntax, its hard to read, I do not see why to stick with 5.2 if 5.3 offers some real performance benefits. I love that most of the cake's source is easy to read and understand, great spirit. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: CakePHP future
The standards you are referring to are most likely the PSR guidelines, and we are looking into ways that we can make CakePHP compatible with the ideas in the guidelines. I think the ability to combine different frameworks and libraries together is generally something that can already be done. There are a few pain points, and I hope to find the time to figure out how to make them less painful. Just because a framework isn't 5.3 only doesn't mean you can't use 5.3 features in your application code. -Mark On Sep 7, 5:53 am, j0n4s.h4rtm...@googlemail.com j0n4s.h4rtm...@googlemail.com wrote: two notes on this: a.) while this might not make me friends: Lithium may be able to pull of both: a.) a very microkernel framework that comes without much tools and with a loose frame (thus bad for newbies and bad programmers like me ;-p) and b.) a standard set of addons extensions plugins whatever: data sources/object mappers, filters, authenfication, access control, etc. Why do I say this? Rails 3 did this (Though the basis of Ruby implies different contraints, some very positive other rather negative) (More on that topic on the rails website under screencasts, Rails 3 Screencast Series, the screencasts show the decoupling of the frame- parts (read framework parts) and the great Arel :)). So I could very well imagen Lithium and Lithium+, though on the other side of the coin - if there will be no Lithium+ in the long run - I do not see it becoming much more popular than ZF though. b.) I do not like general OSS wars, they just consume time. Instead I want to ask a question: Afaik Lithium is committed to some php library standard definitions. Will Cake2 share those? And if that's the case: can you see combined use of both, parts of them and/or integration? p.s: While I do not like php 5.3s syntax, its hard to read, I do not see why to stick with 5.2 if 5.3 offers some real performance benefits. I love that most of the cake's source is easy to read and understand, great spirit. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: CakePHP future
two notes on this: a.) while this might not make me friends: Lithium may be able to pull of both: a.) a very microkernel framework that comes without much tools and with a loose frame (thus bad for newbies and bad programmers like me ;-p) and b.) a standard set of addons extensions plugins whatever: data sources/object mappers, filters, authenfication, access control, etc. Why do I say this? Rails 3 did this (Though the basis of Ruby implies different contraints, some very positive other rather negative) (More on that topic on the rails website under screencasts, Rails 3 Screencast Series, the screencasts show the decoupling of the frame- parts (read framework parts) and the great Arel :)). So I could very well imagen Lithium and Lithium+, though on the other side of the coin - if there will be no Lithium+ in the long run - I do not see it becoming much more popular than ZF though. b.) I do not like general OSS wars, they just consume time. Instead I want to ask a question: Afaik Lithium is committed to some php library standard definitions. Will Cake2 share those? And if that's the case: can you see combined use of both, parts of them and/or integration? p.s: While I do not like php 5.3s syntax, its hard to read, I do not see why to stick with 5.2 if 5.3 offers some real performance benefits. I love that most of the cake's source is easy to read and understand, great spirit. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: CakePHP future
Yup. The Lithium project is the child of a couple of the core Cake developers who left the project around a year ago to do their own thing. If I was Cake and wanted to get all corporatey I could ask them to stop referring to Cake when they mention their project. Jeremy Burns Class Outfit jeremybu...@classoutfit.com http://www.classoutfit.com On 5 Sep 2010, at 05:06, Jamie wrote: The Lithium framework is a completely separate project from CakePHP. It doesn't represent its future or anything like that. It has its roots in the now-defunct Cake 3, but that's as far as it goes... it's totally separate. CakePHP is not affiliated with Lithium. The articles you quote - especially the second one on debuggable.com - are out of date. The main difference between Lithium and CakePHP, aside from being two completely separate frameworks, is that Lithium requires PHP 5.3 since it uses namespaces. CakePHP supports 5.3, but doesn't use any 5.3-only features. - Jamie On Sep 2, 9:10 pm, sambo chhaysa...@gmail.com wrote: Does Lithium framework is the future of CakePHP? And what is different with CakePHP 2.0 and Cake3 (released under a new name: Lithium)? You can see this link below for morehttp://www.phpframeworks.com/news/p/614/cakephp-is-dead-lithium-was-bornhttp://debuggable.com/posts/Cake_3_interview_with_Nate_Abele:4a665a5e... Thanks, Sambo Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: CakePHP future
Lithium is not the future of CakePHP. It is a project that was started by a few cakephp alumni. CakePHP's future is looking bright and development of 2.0 is progressing well. If you are interested in the ongoing development you can keep track of the activity either on github or lighthouse. -Mark On Sep 3, 12:10 am, sambo chhaysa...@gmail.com wrote: Does Lithium framework is the future of CakePHP? And what is different with CakePHP 2.0 and Cake3 (released under a new name: Lithium)? You can see this link below for morehttp://www.phpframeworks.com/news/p/614/cakephp-is-dead-lithium-was-bornhttp://debuggable.com/posts/Cake_3_interview_with_Nate_Abele:4a665a5e... Thanks, Sambo Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: CakePHP future
Wanted to mention that I think Lithium is aimed at a much different class of programmer than CakePHP from what I can tell. Lithium looks like it is good for someone who knows how to build all the functionality they need from scratch and doesn't want anything else in the code that won't be used. CakePHP has a lot of features that help speed along common tasks facing most web developers, and it packs in a lot of functionality out of the box. Just take a look at how much work Mark Story and the gang are putting into these last few builds and you start to get an idea of just how much work is going in to the project. In reality CakePHP 2 is more of a step away from PHP 5 and some of CakPHP's legacy features and not so much a radical departure as Cake3..ahem I mean Lithium. The future of CakePHP looks more like improving on an already good thing that tons of people already use and not necessarily reinventing the wheel to design uber-apps with the hot new framework in town, Lithium (of which I have yet to, and would like to try). But the 5-6 Apps/Sites I have built this last 2 years will need to stay with Cake as far as I am concerned. On Sep 5, 11:46 pm, mark_story mark.st...@gmail.com wrote: Lithium is not the future of CakePHP. It is a project that was started by a few cakephp alumni. CakePHP's future is looking bright and development of 2.0 is progressing well. If you are interested in the ongoing development you can keep track of the activity either on github or lighthouse. -Mark On Sep 3, 12:10 am, sambo chhaysa...@gmail.com wrote: Does Lithium framework is the future of CakePHP? And what is different with CakePHP 2.0 and Cake3 (released under a new name: Lithium)? You can see this link below for morehttp://www.phpframeworks.com/news/p/614/cakephp-is-dead-lithium-was-b.. Thanks, Sambo Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
CakePHP future
Does Lithium framework is the future of CakePHP? And what is different with CakePHP 2.0 and Cake3 (released under a new name: Lithium)? You can see this link below for more http://www.phpframeworks.com/news/p/614/cakephp-is-dead-lithium-was-born http://debuggable.com/posts/Cake_3_interview_with_Nate_Abele:4a665a5e-5bfc-4e42-96ee-6d284834cda3 Thanks, Sambo Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: CakePHP future
good questions..I look forward to reading what people say on this.. On Thu, Sep 2, 2010 at 9:10 PM, sambo chhaysa...@gmail.com wrote: Does Lithium framework is the future of CakePHP? And what is different with CakePHP 2.0 and Cake3 (released under a new name: Lithium)? You can see this link below for more http://www.phpframeworks.com/news/p/614/cakephp-is-dead-lithium-was-born http://debuggable.com/posts/Cake_3_interview_with_Nate_Abele:4a665a5e-5bfc-4e42-96ee-6d284834cda3 Thanks, Sambo Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.comcake-php%2bunsubscr...@googlegroups.comFor more options, visit this group at http://groups.google.com/group/cake-php?hl=en Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: CakePHP future
The Lithium framework is a completely separate project from CakePHP. It doesn't represent its future or anything like that. It has its roots in the now-defunct Cake 3, but that's as far as it goes... it's totally separate. CakePHP is not affiliated with Lithium. The articles you quote - especially the second one on debuggable.com - are out of date. The main difference between Lithium and CakePHP, aside from being two completely separate frameworks, is that Lithium requires PHP 5.3 since it uses namespaces. CakePHP supports 5.3, but doesn't use any 5.3-only features. - Jamie On Sep 2, 9:10 pm, sambo chhaysa...@gmail.com wrote: Does Lithium framework is the future of CakePHP? And what is different with CakePHP 2.0 and Cake3 (released under a new name: Lithium)? You can see this link below for morehttp://www.phpframeworks.com/news/p/614/cakephp-is-dead-lithium-was-bornhttp://debuggable.com/posts/Cake_3_interview_with_Nate_Abele:4a665a5e... Thanks, Sambo Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: Planning on CakePHP future versions
On 10/24/06, nate [EMAIL PROTECTED] wrote: In what way did it break your apps? I'm curious because in the last Thanks for the attention - here it goes In the security fix release - Components were suddenly not available in the contructor of app_controller.php of an application - this was not due to removal of any deprecated function but due to moving of the said code outside - I can provide exact diffs if you want. Then in the CakePHP 1.1.8.3544 - Doing requestAction() on a plugin twice in the same function/method started giving a fatal error - We traced it to code changes in dispatcher.php and a possible bug in loadController function - this was posted at http://groups.google.com/group/cake-php/browse_thread/thread/7bf93ea9c79fe57e/ but it got missed by everyone... I am now curious as to where we did not play by the rules in the above two cases :) Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Coppermine Picture Gallery: http://coppermine.sf.net = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
2006/10/25, Dr. Tarique Sani [EMAIL PROTECTED]: I am now curious as to where we did not play by the rules in the above two cases :) I suppose you should have filed a ticket in Trac (http://trac.cakephp.org/). Martin -- Martin Schapendonk, [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
The second case I can't really help you out on, since the plugins interface is the one department of the framework I tend to stay out of, but I will say that yes, we usually completely ignore any bugs reported on the mailing list, as they should be reported on Trac. The first case, however, is probably our fault for not making clear. In most objects __construct is not designed to do any work outside the scope of that object. In fact, you should almost never need to use __construct in a controller, as beforeFilter fills the same role just fine. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
RE: Planning on CakePHP future versions
Nate, I think that's already properly documented. I've been using beforeFilter() for that purpose and I don't possess any mind reading skills that I know of, so I must have read it somewhere. I've also been going through the Cake PDF manual and it is quite well designed, as it helps developers bake in the proper way. That said, some things can become big issues, but I think we should also understand that Cake is an open source work in progress, so it requires our help. Both for letting the cake team know what could be improved, but also by participating in the development and/or documentation efforts. That's the way open source projects work in the end. -MI -Original Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of nate Sent: Wednesday, October 25, 2006 2:37 PM To: Cake PHP Subject: Re: Planning on CakePHP future versions The second case I can't really help you out on, since the plugins interface is the one department of the framework I tend to stay out of, but I will say that yes, we usually completely ignore any bugs reported on the mailing list, as they should be reported on Trac. The first case, however, is probably our fault for not making clear. In most objects __construct is not designed to do any work outside the scope of that object. In fact, you should almost never need to use __construct in a controller, as beforeFilter fills the same role just fine. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/496 - Release Date: 10/24/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/496 - Release Date: 10/24/2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
On 10/25/06, nate [EMAIL PROTECTED] wrote: we usually completely ignore any bugs reported on the mailing list, as they should be reported on Trac. OK! I will have the programmer who found this put it in trac and hope is it looked into. The first case, however, is probably our fault for not making clear. In most objects __construct is not designed to do any work outside the scope of that object. Thanks for the explaination - would have been very helpful if this was put in the trac issue report before closing it - beforeFilter is what I am using now. @MI - I am exactly doing what you are suggesting :) I head a few open source projects which have more than a couple of million downloads so can say that I know your pain. There is also a flip side to the coin you are describing but talking about that would be digressing. Thanks again Nate. Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Coppermine Picture Gallery: http://coppermine.sf.net = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
RE: Planning on CakePHP future versions
Tarique, By no means had I suggested you were not involved in the ongoing development of Cake or any other open source project. It was more of a general statement, because as a developer of several projects and owner of free programming sites sometimes you just get frustrated with the amounts of people that get in just to ask a question, they get the answer, and then they never give something back to the community. Agree, let's not digress anymore. I've just wanted to point out that my comment was not directed at you. -MI -Mensaje original- De: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] En nombre de Dr. Tarique Sani Enviado el: Jueves, 26 de Octubre de 2006 01:57 a.m. Para: cake-php@googlegroups.com Asunto: Re: Planning on CakePHP future versions @MI - I am exactly doing what you are suggesting :) I head a few open source projects which have more than a couple of million downloads so can say that I know your pain. There is also a flip side to the coin you are describing but talking about that would be digressing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
On 10/23/06, gwoo [EMAIL PROTECTED] wrote: so for some time you should have no worries about dropping the cake core into any project and watchingit work.I would like to qualify the above with watch it work most of the time Last two minor versions of cake broke my Cheesecake app which was running OK with the immediate previous version. While the refactoring needed for making it work again was small - it does pose a problem when you are coding commercially and / or for large projects. CheersTarique-- =PHP Applications for E-Biz: http://www.sanisoft.comCoppermine Picture Gallery: http://coppermine.sf.net= --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
In what way did it break your apps? I'm curious because in the last release, we started removing deprecated methods, which will happen again in 1.2. The methods that were removed in the previous release had been deprecated for several release cycles, some even before 1.0 final. So, I guess the stipulation is, as long as you follow the rules, you should have no issues upgrading. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Re: Planning on CakePHP future versions
Nate is it possible to have deprecated methods through notices in debug mode but work in deployment for deprecated methods for a release or two before the scheduled removal. Given that there are more and more sites built on CakePHP that are in production? SD On 10/24/06, nate [EMAIL PROTECTED] wrote: In what way did it break your apps? I'm curious because in the last release, we started removing deprecated methods, which will happen again in 1.2. The methods that were removed in the previous release had been deprecated for several release cycles, some even before 1.0 final. So, I guess the stipulation is, as long as you follow the rules, you should have no issues upgrading. -- == S. DeVore (the old fart) the advice is free, the lack of crankiness will cost you --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
RE: Planning on CakePHP future versions
That would be interesting, considering that otherwise you would have to go through the API to look for deprecated methods. A proper procedure for version upgrading on sites that are in production with Cake will definitely make Cake stand amongst the rest. I also agree with Nate that bakers should play by the rules or then it would make cake's job quite difficult. But having a heads up on which methods will be deprecated on future versions (I understand you can't predict what will happen on Cake 11.x, but you can on Cake 2.x) definitely helps us bakers follow the rules. Bake on! -MI -Original Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Samuel DeVore Sent: Tuesday, October 24, 2006 10:46 AM To: cake-php@googlegroups.com Subject: Re: Re: Planning on CakePHP future versions Nate is it possible to have deprecated methods through notices in debug mode but work in deployment for deprecated methods for a release or two before the scheduled removal. Given that there are more and more sites built on CakePHP that are in production? SD -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/493 - Release Date: 10/23/2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
Guys, my own opinion on this. For the future stability and wider acceptance of CakePHP, you should never remove any deprecated methods. Anything that introduces instability into the product, reduces its acceptance into the wider developer community. At the least, you end up stuck on older releases because you dare not upgrade an existing clients website. At worst, you dont use CakePHP because of the added instability. eg. Java has lots of deprecated classes and methods, but I dont believe any of them have ever been removed. Why? Stability. Many applications just cannot afford the time to revisit existing code. If I use CakePHP to develop multiple websites, and each of them ends up on a different Cake release because I dare not upgrade, thats gonna be a major headache! Deprecate as much a required, but please,please,please dont make the product unstable by breaking existing code! If it has to to be done at all, say for justifiable perfomance reasons, can we make this something that happens very rarely. I like the product so far, but for me to use it in anger, it has to be stable. Glad to hear others opinions on this... C --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
We do not remove deprecated until there is a major version change. Nate was referring to methods that have been deprecated since 0.10, which came out over a year ago. Otherwise, trigger_error is used to send a warning. The most important thing here is that we need communication from the community when there is a problem. Without tickets we can do nothing to help you. If you want to blog about your problems or bug you found, great for you, but it does the rest of the community no good unless they go searching for an hour to find your post. This project is thriving because of the support of its community members. There are more and more people joining everyday. So, please if you find functionality that bothers you submit an RFC ticket, if you find a problem that you don't think should exists, submit a bug ticket. Your blog and this group are not the places for bug reports or RFCs. We have a development site dedicated to making CakePHP better. Please use it. Also, along this line, if you are a new member or old member you should spend a few minutes searching the google group for answers. This project has been going for a while and there are probably over 20,000 posts in the groups. Yes that is a lot to search through, but often the answer you need is in the first two or three posts you search for. Remember, we have a google group because supposedly it has the best underlying search technology. Please use it. Bake on. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
RE: Planning on CakePHP future versions
I think that at some point you may find the necessity to remove deprecated methods. Java will remove deprecated methods on future versions (i.e: post tigris) and will also remove certain APIs from their SE distributions. Why? A simple reason that can also be applied for cake: avoiding the constant increase of the core package size. I agree there are some applications that may stick to a specific Cake version just because of a decision of keeping what they know works (see Oscommerce). If that's the case, then you can for example stick to Cake 1.1.x and don't upgrade to future versions. That may not be the smartest decision (since you would miss on new features or even security patches) but it's a developer's decision after all. But I don't think every method that was ever in Cake should remain available on all future versions. If you have a clear understanding of what each version introduces or removes, and you have a long heads up, then you should be OK to go. If you are running your application on Cake 1.x on production mode, and you start reading that Cake 2.x will no longer support (just for the sake of this argument) layout elements, then you may decide to stick to your core Cake package, or update your application to reflect the changes. I think it's more important to have clear documentation on how future versions of Cake will impact on your current installation than to avoid removing deprecated methods. -MI -Original Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of funkyfresh Sent: Tuesday, October 24, 2006 12:11 PM To: Cake PHP Subject: Re: Planning on CakePHP future versions Guys, my own opinion on this. For the future stability and wider acceptance of CakePHP, you should never remove any deprecated methods. Anything that introduces instability into the product, reduces its acceptance into the wider developer community. At the least, you end up stuck on older releases because you dare not upgrade an existing clients website. At worst, you dont use CakePHP because of the added instability. eg. Java has lots of deprecated classes and methods, but I dont believe any of them have ever been removed. Why? Stability. Many applications just cannot afford the time to revisit existing code. If I use CakePHP to develop multiple websites, and each of them ends up on a different Cake release because I dare not upgrade, thats gonna be a major headache! Deprecate as much a required, but please,please,please dont make the product unstable by breaking existing code! If it has to to be done at all, say for justifiable perfomance reasons, can we make this something that happens very rarely. I like the product so far, but for me to use it in anger, it has to be stable. Glad to hear others opinions on this... C -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/493 - Release Date: 10/23/2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
The Java argument also doesn't really hold up, because in most cases, methods are simply renamed, or moved to a different object. Which means that updating an app to the current release is usually a simple matter of a search-and-replace. It also doesn't hurt to be an efficient coder, and have automated tests set up for your application so you don't have to go searching for those things... All other 1.2 API changes are additive, which means added methods, and added parameters to existing methods, which means that all 1.1 code that uses non-deprecated methods is completely forwards-compatible. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
RE: Planning on CakePHP future versions
Well but you're saying the same: that uses non deprecated methods. In the moment that you have to do a search replace you are following what I was saying: sometimes even with java YOU DO NEED to do SR. -MI -Original Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of nate Sent: Tuesday, October 24, 2006 1:31 PM To: Cake PHP Subject: Re: Planning on CakePHP future versions The Java argument also doesn't really hold up, because in most cases, methods are simply renamed, or moved to a different object. Which means that updating an app to the current release is usually a simple matter of a search-and-replace. It also doesn't hurt to be an efficient coder, and have automated tests set up for your application so you don't have to go searching for those things... All other 1.2 API changes are additive, which means added methods, and added parameters to existing methods, which means that all 1.1 code that uses non-deprecated methods is completely forwards-compatible. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/493 - Release Date: 10/23/2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
What I'm saying about Java is that it's usually a bit more complex than a quick SR. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
just for kicks I did move a couple of sample projects to the new core stuff and other then the chaning of the index.php files and some tweeking of config files they all seemed to move fine. No rigorous testing but initially pretty good Sam D On 10/23/06, Mariano Iglesias [EMAIL PROTECTED] wrote: Hi fellow bakers, I have a general question. I am currently developing a very large web application using CakePHP latest stable build (1.1.8.3544) and I am now wondering on the proper procedure for updating Cake's core with future stable releases. Particularly: * When (approximately) will 1.2 stable (a.k.a 2.x as I've seen) be released? * Will there be significant changes to a cake based application's core (not Cake's core) ? For example: Controller class is now called BaseController :) * Will there be a documentation / manual to help upgrade 1.1.x based cake apps into 1.2 ? Basically I am wondering how to prepare for upgrades. I know almost every baker is closely trying to avoid the temptation of touching cake's core, but I've also seen some frameworks that gave such big turns with their upgrades that was almost impossible to upgrade your installation without having to re-do large chunks of code. Thanks! -MI -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/492 - Release Date: 10/23/2006 -- == S. DeVore (the old fart) the advice is free, the lack of crankiness will cost you --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Planning on CakePHP future versions
The API is not changing until 2.0, so for some time you should have no worries about dropping the cake core into any project and watching it work. We are writing documentation for 1.2, but the goal is to allow people to easily upgrade without any worry. To us, there is no point in creating a new version if it breaks any functionality in your apps. Look at the adoption of php5 and you will see why its a bad idea. We do not want to maintain two versions. So, we will keep things stable and just add functionality on top of what's there. Bake on. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
RE: Planning on CakePHP future versions
Hi gwoo (kewl name btw), Will there be major changes on the API on 2.0? I know that soon you'll make i18n available, so for example in my case I would have to move out of current PEAR's Translation2 implementation I use for i18n towards cake internationalization, but in this case that's something that wouldn't have a major impact on my application (easy to change.) I applaud the spirit of trying to avoid a major impact on developer's applications, as long as they are playing by the rules (not modifying the core.) I am truly becoming a CakePHP fan, and hopefuly when we finish the application you guys will have a large web app as an example of corporate development using CakePHP. Bake on! -MI -Original Message- From: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of gwoo Sent: Monday, October 23, 2006 12:15 PM To: cake-php@googlegroups.com Subject: Re: Planning on CakePHP future versions The API is not changing until 2.0, so for some time you should have no worries about dropping the cake core into any project and watching it work. We are writing documentation for 1.2, but the goal is to allow people to easily upgrade without any worry. To us, there is no point in creating a new version if it breaks any functionality in your apps. Look at the adoption of php5 and you will see why its a bad idea. We do not want to maintain two versions. So, we will keep things stable and just add functionality on top of what's there. Bake on. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.11/492 - Release Date: 10/23/2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
