3.0: a peek into CakePHP's future
Locked
3.0: a peek into CakePHP's future
 
|
Since its creation, more than 7 years ago, CakePHP has grown with a life of its own. Its main goal has always been to empower developers with tools that are both easy to learn and use, leverage great libraries requiring low documentation and low dependencies too. We've had several big releases along these years and an ever growing community. Being one of the most popular frameworks out there and probably the first one (!) we have also gotten a lot of criticism from the developer community in general. We have, though, accepted it and learnt from our mistakes to keep building the best PHP framework there is. CakePHP is known for having a very slow pace of adopting new stuff and it has served very well to its community. Back when we were doing version 2.0 we decided to hold on version 5.2 of PHP for multiple reasons and despite it didn't let us innovate as much as we wished to, it was an excellent choice given the general environment regarding hosting solutions and general adoption of PHP 5.3. A look back into the past reminded us that we were big innovators in PHP, bringing features to developers that few dreamt possible to do in this language. Now, it's time to look ahead in future and decide on staying in our comfort zone or take back our leading position as innovators. So it is with great excitement that we announce we are putting our our efforts in bringing you the next major release of CakePHP. Version 3.0 will leverage the new features in PHP 5.4 and will include an important change in our models and database system. CakePHP 3.0 will not be ready less than 6 or 8 months and we reckon that, given the rise of cheap cloud hosting solutions and upcoming release of new operating system versions, there is no better time to jump on the most current stable version of PHP. As you may already know, PHP 5.4 offers awesome features that would introduce useful new concepts and interesting solutions to old problems. Closure binding, traits, multibyte support are tools we see of great usefulness for properly implemented advanced framework features we've had in mind for a long time. Also new syntax sugar added to the language will make it more pleasant to write both small and complex applications with the framework and a always welcomed free performance increase. We have a young but already well defined road map for what we want to accomplish in next release and you are invited to contribute and suggest what's next:
As you may imagine most of the time will be spent or rewriting the model layer, but it will also be one of the most powerful features CakePHP 3.0 will have. It's new architecture based on PHP 5.4 capabilities will offer an easier and more powerful set of tools to build web applications in no time. If you are already as excited as we are this all this new stuff coming, you definitely should meet us on next CakeFest we'll be talking about the future of CakePHP and hacking our way through to bring you a dev release as soon as possible. Wouldn't it be lovely to attend to awesome talks, workshops and also be part of the group deciding initial architecture for next major version of the framework? Make sure you book your tickets before we run out of them! We're always looking for different people having a vision on software development, are you interested in helping out? There is no better time to start sending patches and become one of the core team! --Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
|
Why the removal of named parameters in the Router? They are quite useful to me and the Paginator uses them to keep track of page.
What would be used instead? -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
On Fri, Jul 6, 2012 at 9:47 AM, Ilie <[hidden email]> wrote:
> Why the removal of named parameters in the Router? They are quite useful to > me and the Paginator uses them to keep track of page. > > What would be used instead? > Guess named routes and smarter prefixes in combo will probably work the same Just a speculation T -- ============================================================= PHP for E-Biz: http://sanisoft.com ============================================================= -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
|
In reply to this post by José Lorenzo
On Friday, July 6, 2012 4:36:03 AM UTC+2, José Lorenzo wrote: The new model layer will be an exciting feature. But it also looks like it is going to be very different from CakePHP 2. Is there going to be an update path for CakePHP 2 apps to CakePHP 3? k -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
In reply to this post by José Lorenzo
Hi!
First of all, big kudos to the developers of CakePHP. It is an excellent, well thought out and well engineered framework. It does indeed look very traditional and conservative and that is a Good Thing(tm). That's why I see with horror the mention of moving to the objects returned by models from queries. Would you leave them alone, please? We work in a data-centric environment here and there is nothing better than associative arrays to do that. Please, leave data alone and better improve the handling of data arrays where the effects of various calls are not obvious. That will be a much better deal. I do not expect that many people selected CakePHP in the hope that it would move to object-oriented data. There are other frameworks for that. Thank you. Albert aka Tigr On Friday, July 6, 2012 4:36:03 AM UTC+2, José Lorenzo wrote: -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
In reply to this post by Kazik
Does it mean Cake 3.0´s Model will return objects instead of arrays ?
On Fri, Jul 6, 2012 at 6:33 AM, Kazik <[hidden email]> wrote:
-- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
|
On Fri, Jul 6, 2012 at 2:17 PM, Marsson C. <[hidden email]> wrote:
> > Does it mean Cake 3.0´s Model will return objects instead of arrays ? Yes "Model layer rewrite: Models to return objects from queries" -- Andy Gale http://andy-gale.com http://twitter.com/andygale -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
|
nice :) Von: Andy Gale <[hidden email]> An: [hidden email] Gesendet: 15:19 Freitag, 6.Juli 2012 Betreff: Re: 3.0: a peek into CakePHP's future On Fri, Jul 6, 2012 at 2:17 PM, Marsson C. <[hidden email]> wrote: > > Does it mean Cake 3.0´s Model will return objects instead of arrays ? Yes "Model layer rewrite: Models to return objects from queries" -- Andy Gale http://andy-gale.com http://twitter.com/andygale -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to cake-php+[hidden email] For more options, visit this group at http://groups.google.com/group/cake-php Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
|
In reply to this post by Ilie
They were just a bad copy of the query string with tons of problems and performance issues. They will continue to work in read-only mode, but cake will produce query string variables instead.
On Thursday, July 5, 2012 11:47:10 PM UTC-4:30, Ilie wrote: Why the removal of named parameters in the Router? They are quite useful to me and the Paginator uses them to keep track of page.-- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
|
In reply to this post by Marsson C.
On Friday, July 6, 2012 8:47:18 AM UTC-4:30, Marsson wrote: Does it mean Cake 3.0´s Model will return objects instead of arrays ? Yes :) -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
|
In reply to this post by Albert 'Tigr'
On Friday, July 6, 2012 6:12:47 AM UTC-4:30, tigr wrote: Hi! You will be able to work with the table object and have arrays returned back. Models (rows) will be objects, though. Thank you.-- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
|
I'm also cautious about moving to objects. I really like the way
Cake's arrays work. However, I presume that this will mean that the model will be available in the view, which will be useful in some cases. Whatever the case, I'm looking forward to 3. -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
In reply to this post by José Lorenzo
I've worked with Cake since the 1.1 release, and recently I've worked a lot with Symfony, and on larger scale apps, which has helped me understand the strengths and weaknesess of both frameworks. So, a chance to express an opinion on the future of Cake? How could I possibly resist :) (Disclaimer: All of this is just my opinion /POV, not preaching here...) Obviously it's important not to throw the baby out with the bath water - DRY, Convention over config, auto-magic/scaffold features, etc are some of the key features that differentiate Cake from other frameworks, and losing this for the sake of a design pattern or a ridiculous amount of abstraction shouldn't be risked. * A clearer Dependency Injection model for core classes. I didn't think Cake had anything like this then I read a post on overriding the Request class, and I was like 'is this DI?' SF2 has a DI component that can be reused for this I think. * Appropriate use of arrays. There's a time and a place for arrays, and, imho, data is a good use, and advanced config is not. I love Cake's convention over config approach (vs the bloated yaml files of Symfony) but when you *do* need that config, arrays won't cut-it for more complex stuff. The support for ini files in Cake 2 is a great step forward in this, and, imho, json, xml, and ini files should be natively supported for some app config, and similar for value-object creation. * Greater modularity - obviously the move to name spaces (and I hope PSR standards?) is linked to this. I think partitioning the folders as per https://groups.google.com/forum/?fromgroups#!topic/cake-php/msttsVAG9tI, and making the different libraries work independently, would be ideal- why shouldn't someone be able to use the SF2 Router and the ZF Controller layer and the Cake model layer if that's what works for them? Or migrate their enterprise app over to another framework incrementally? For example, take the model layer- Imho, the model later is one of Cake's best features, and changes should be cautious. * Standalone library - I think being able to use Cake's model layer as a stand-alone would massively increase the mind-share of Cake. * OO changes - it's a matter of opinion, but Cake's arrays aren't really a massive issue for me. Given you can usually access arrays with object syntax, and there's various community behaviors to achieve this effect anyway, I don't think this a deal breaker. Value Objects makes some sense, but I personally hope Cake never goes the way of $record->save, and always keeps with $model->save. Imho, putting too much DB behaviour into the row-level objects leads to a much more complex system, where it's a lot easier to implement poor SQL. If people want that approach, don't re-invent the wheel, Doctrine and Propel are mature libs and they don't need any more competitors :) One places the models could definitely do with a revamp is the setting of validation rules. Once I'm 4 levels deep into the array config, I wish I was making classes or objects or using a separate config format! Okay, sorry for the rant, but I'd be interested to see how closely my views align with the community at large... On Friday, 6 July 2012 03:36:03 UTC+1, José Lorenzo wrote:
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
|
|
I'm excited to try out 3.0 but please, PLEASE don't make Cake into
anything like Symfony! Do. Not. Like. I agree that model validation could use some freshening, although I don't personally have any great ideas for doing that. I don't understand the desire to use parts of one framework with another, btw. Or even using the model layer on its own. I know I may just be missing something but it seems bizarre to me. On Fri, Jul 6, 2012 at 5:50 PM, the_woodsman <[hidden email]> wrote: > > I've worked with Cake since the 1.1 release, and recently I've worked a lot > with Symfony, and on larger scale apps, which has helped me understand the > strengths and weaknesess of both frameworks. > > So, a chance to express an opinion on the future of Cake? How could I > possibly resist :) > > (Disclaimer: All of this is just my opinion /POV, not preaching here...) > > Obviously it's important not to throw the baby out with the bath water - > DRY, Convention over config, auto-magic/scaffold features, etc are some of > the key features that differentiate Cake from other frameworks, and losing > this for the sake of a design pattern or a ridiculous amount of abstraction > shouldn't be risked. > > * A clearer Dependency Injection model for core classes. I didn't think > Cake had anything like this then I read a post on overriding the Request > class, and I was like 'is this DI?' SF2 has a DI component that can be > reused for this I think. > > * Appropriate use of arrays. There's a time and a place for arrays, and, > imho, data is a good use, and advanced config is not. > I love Cake's convention over config approach (vs the bloated yaml files of > Symfony) but when you *do* need that config, arrays won't cut-it for more > complex stuff. > The support for ini files in Cake 2 is a great step forward in this, and, > imho, json, xml, and ini files should be natively supported for some app > config, and similar for value-object creation. > > * Greater modularity - obviously the move to name spaces (and I hope PSR > standards?) is linked to this. > I think partitioning the folders as per > https://groups.google.com/forum/?fromgroups#!topic/cake-php/msttsVAG9tI, and > making the different libraries work independently, would be ideal- why > shouldn't someone be able to use the SF2 Router and the ZF Controller layer > and the Cake model layer if that's what works for them? Or migrate their > enterprise app over to another framework incrementally? > > For example, take the model layer- Imho, the model later is one of Cake's > best features, and changes should be cautious. > * Standalone library - I think being able to use Cake's model layer as a > stand-alone would massively increase the mind-share of Cake. > * OO changes - it's a matter of opinion, but Cake's arrays aren't really a > massive issue for me. Given you can usually access arrays with object > syntax, and there's various community behaviors to achieve this effect > anyway, I don't think this a deal breaker. > > Value Objects makes some sense, but I personally hope Cake never goes the > way of $record->save, and always keeps with $model->save. > Imho, putting too much DB behaviour into the row-level objects leads to a > much more complex system, where it's a lot easier to implement poor SQL. > If people want that approach, don't re-invent the wheel, Doctrine and > Propel are mature libs and they don't need any more competitors :) > > One places the models could definitely do with a revamp is the setting of > validation rules. > Once I'm 4 levels deep into the array config, I wish I was making classes or > objects or using a separate config format! > > > Okay, sorry for the rant, but I'd be interested to see how closely my views > align with the community at large... > > > On Friday, 6 July 2012 03:36:03 UTC+1, José Lorenzo wrote: >> >> Since its creation, more than 7 years ago, CakePHP has grown with a life >> of its own. Its main goal has always been to empower developers with tools >> that are both easy to learn and use, leverage great libraries requiring low >> documentation and low dependencies too. We've had several big releases along >> these years and an ever growing community. Being one of the most popular >> frameworks out there and probably the first one (!) we have also gotten a >> lot of criticism from the developer community in general. We have, though, >> accepted it and learnt from our mistakes to keep building the best PHP >> framework there is. >> >> CakePHP is known for having a very slow pace of adopting new stuff and it >> has served very well to its community. Back when we were doing version 2.0 >> we decided to hold on version 5.2 of PHP for multiple reasons and despite it >> didn't let us innovate as much as we wished to, it was an excellent choice >> given the general environment regarding hosting solutions and general >> adoption of PHP 5.3. A look back into the past reminded us that we were big >> innovators in PHP, bringing features to developers that few dreamt possible >> to do in this language. Now, it's time to look ahead in future and decide on >> staying in our comfort zone or take back our leading position as innovators. >> >> So it is with great excitement that we announce we are putting our our >> efforts in bringing you the next major release of CakePHP. Version 3.0 will >> leverage the new features in PHP 5.4 and will include an important change in >> our models and database system. CakePHP 3.0 will not be ready less than 6 or >> 8 months and we reckon that, given the rise of cheap cloud hosting solutions >> and upcoming release of new operating system versions, there is no better >> time to jump on the most current stable version of PHP. >> >> As you may already know, PHP 5.4 offers awesome features that would >> introduce useful new concepts and interesting solutions to old problems. >> Closure binding, traits, multibyte support are tools we see of great >> usefulness for properly implemented advanced framework features we've had in >> mind for a long time. Also new syntax sugar added to the language will make >> it more pleasant to write both small and complex applications with the >> framework and a always welcomed free performance increase. >> >> We have a young but already well defined road map for what we want to >> accomplish in next release and you are invited to contribute and suggest >> what's next: >> >> Drop support for 5.2.x and support 5.4+ only >> Add proper namespaces for all classes. This will make it easier to reuse >> classes outside CakePHP and to use external libraries and finally no chances >> of collisions between your app classes and core ones. >> Use traits were possible and makes sense >> Improve bootstrapping process to allow more developer control and better >> performance >> Model layer rewrite: >> >> Models to return objects from queries >> Datamapper-like paradigm >> Richer query API >> Support for any database type >> Support for more database drivers both PDO and native >> >> Improve Router: >> >> Make it faster >> Remove named parameters >> Add support for named routes >> Smarter router prefixes >> Shorter url syntax >> >> As you may imagine most of the time will be spent or rewriting the model >> layer, but it will also be one of the most powerful features CakePHP 3.0 >> will have. It's new architecture based on PHP 5.4 capabilities will offer an >> easier and more powerful set of tools to build web applications in no time. >> >> If you are already as excited as we are this all this new stuff coming, >> you definitely should meet us on next CakeFest we'll be talking about the >> future of CakePHP and hacking our way through to bring you a dev release as >> soon as possible. Wouldn't it be lovely to attend to awesome talks, >> workshops and also be part of the group deciding initial architecture for >> next major version of the framework? Make sure you book your tickets before >> we run out of them! >> >> We're always looking for different people having a vision on software >> development, are you interested in helping out? There is no better time to >> start sending patches and become one of the core team! > > -- > Our newest site for the community: CakePHP Video Tutorials > http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help > others with their CakePHP related questions. > > > To unsubscribe from this group, send email to > [hidden email] For more options, visit this group at > http://groups.google.com/group/cake-php -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
|
In reply to this post by José Lorenzo
No, that is not "nice". The strength of the CakePHP design is in being very straightforward when it comes to working with the data. I have seen other frameworks and I think that object-oriented ways are not suitable for working with data. Well, of course, you can, but would you want to, given a choice? My answer was "no" and that is why I am using Cake. I am worried that the object-oriented hype will get the best of you and we will lose a perfectly sensible data processing framework to the object-oriented glory. For practical reasons, it would be great to leave the model layer principles as they are.
-- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
On Saturday, 7 July 2012 11:35:08 UTC+2, tigr wrote: No, that is not "nice". The strength of the CakePHP design is in being very straightforward when it comes to working with the data. I have seen other frameworks and I think that object-oriented ways are not suitable for working with data. Well, of course, you can, but would you want to, given a choice? My answer was "no" and that is why I am using Cake. I am worried that the object-oriented hype will get the best of you and we will lose a perfectly sensible data processing framework to the object-oriented glory. For practical reasons, it would be great to leave the model layer principles as they are. my few cents: a.) fork it b.) if cake is decoupled enough = forking will be easy (e.g. the decoupling between model layer from controller layer from view helper etc.) c.) instead of forking, add a 2nd model layer abstraction d.) learn from rails3 e.) look at how well AREL works so for me the questions are rather: can a similar decoupling be done well in php 5.4; can we get true objects or just read only? if we get read only, can't we just enable a bool to return nested data arrays? Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
In reply to this post by Albert 'Tigr'
For mine, being able to deal with objects in the view would greatly improve the readability of data (the whole $user['User']['email'] etc looks incredibly difficult to read to me, compared with $user->email which would be much nicer).
I've always felt dealing with arrays is a bit of a 'hack'. I understand the choice, but I think the idea to move towards a more object oriented approach is more than hype, and long overdue.
On Sat, Jul 7, 2012 at 7:35 PM, tigr <[hidden email]> wrote: No, that is not "nice". The strength of the CakePHP design is in being very straightforward when it comes to working with the data. I have seen other frameworks and I think that object-oriented ways are not suitable for working with data. Well, of course, you can, but would you want to, given a choice? My answer was "no" and that is why I am using Cake. I am worried that the object-oriented hype will get the best of you and we will lose a perfectly sensible data processing framework to the object-oriented glory. For practical reasons, it would be great to leave the model layer principles as they are. -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
I would think moving to a more object oriented model will result in better readable code and IDE auto completion will be more useful.
On Sunday, July 8, 2012 7:12:32 PM UTC-7, Greg wrote: For mine, being able to deal with objects in the view would greatly improve the readability of data (the whole $user['User']['email'] etc looks incredibly difficult to read to me, compared with $user->email which would be much nicer).-- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
Wouldn't array be still used? For instance more than one objects are passed, should the objects be stored in an array? What would happen to the auto conversion to json? Array is easier to convert to json rite? On Jul 10, 2012 1:19 AM, "Jamescowhen" <[hidden email]> wrote:
-- I would think moving to a more object oriented model will result in better readable code and IDE auto completion will be more useful. Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
Re: 3.0: a peek into CakePHP's future
|
http://php.net/manual/en/class.serializable.php :).
On Tuesday, July 10, 2012 3:57:20 AM UTC+2, madi wrote: -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/cake-php |
| Powered by Nabble | Edit this page |