RedBean has in its API's an Rest Server till version 3.5
http://redbeanphp.com/manual3_0/rest_server
I was wondering where to find RedBean_Plugin_BeanCanResty for RedBean 4? Since it isn't listed in the API any more. Is it still available? or is it deprecated?
It's been removed, but is still available as a plugin according to their changelog:
Why are the BeanCan Servers gone?
They blurred the distinction between plugin and core. Also, the RedBeanPHP Adaptive branch is going more in the direction of a framework which is a better place for BeanCan as well. RedBeanPHP 4 returns to the core of the library: on-the-fly ORM. Another reason is that it turns out it is pretty much impossible to prescribe the interface of a JSON or REST API.
This functionality is still available as a plugin
Related
As a developer I have to make a upfront commitment for 5 years support for a new Laravel project.
My question is - whether I should use Laravel's Long Term Support (LTS) version only?
What could be the potential pitfalls with regards to the support commitment if I use the latest Laravel 5.3 instead of the LTS version?
Any information regarding points to be considered like pros/cons with regards to the support commitment for 5 years when using the latest Laravel version versus using LTS version would help me make a correct decision.
To keep your application framework-agnostic, or to make it easier to swap out or not depend on the framework, the approach which worked the best for me was to isolate my business logic in separate libraries.
I handle those libraries using GITLab server, and I expose them to my composer via satis.
If you use Laravel's routing to map request to a controller, then you can use your library inside that controller and perform the rest of the work.
Constructing your app this way lets you:
isolate business logic
rely on framework to provide correct input since you can use middleware to filter out requests that don't fit.
have it easier when it comes to swapping the framework out
you're using composer, which lets you easily manage library and framework version(s)
This way, you can upgrade your app bit by bit as time goes by, you don't have to rely on having only one framework version forever, without being able to use newer releases.
Good luck with your project!
Actually, I am working on a project with Laravel5 (laravel.com)
someone who is working on another project with SailsJS (sailsjs.org) asked me why I am still using PHP. I should work with nodejs (sails), because PHP would be a language would be going to die.
Well, what's better to use for the future.
Both are MVC frameworks
on both you can code views with Jade (see jade-lang.org)
on both you can use any database.
on both you can easily install modules (composer / npm for the backend), bower for the frontend
What's better - and an important aspect - which framework creates responds faster?
As a technical guy, i would suggest you to use sails over laravel. Its not because PHP is going to die(and it will not happen).
As far as i know, anything built on javascript would be faster.
There are lot of advantages in sails like sockets are very easy to implement so on.
When it comes to disadvantage, its only with DOCUMENTATION. For a beginner, it would become little difficult to grasp all the things.
From PHP (Synchronous) to sails(Assynchronous), it will take some time to get familiar with sails.
Make sure you understand the basics of node.js very well before you start with sails.
For more references, see this , this and this
PHP is never going to die, Choosing a technology stack all depends on application & available resource, If you have expertise in php then you will obviously take longer time building app in nodejs/sails.
I have worked on both frameworks (sailsjs & larave 5.2) and for my new project i will go with laravel because:
Laravel is pretty mature framework (was founded in 2011 and has 9K contributors)
It got builtin support for most of things like migraters, seeders, queuing system and templates.
Documentation is very good.
lots of 3rd party integration, you can integrate it with s3-buckets, dropbox any email service provider and backup services in few minutes. complete list of integrations
Disadvantage of laravel:
Socket support is poor, but you can do socket part in nodejs, and can
bridge that using REST APIS.
Mongodb support is not good.
I am going to develop website by using Yii framework. I will use netbeans to do it (and if it will be possible) with build-in Yii plugin. And here is my dilemma:
Should I use newest 2.0 version, which is demo version since yet, or use version 1.1.14, which is suported by my netbeans plugin. On official site of Yii I found quite good documentation for 2.0 version. Could you help me with some advices? Will be 1.1.14 version still suported be Yii community, could I use it without lot of painful searching for documentation or it would be better to stick with newest version?
Directly from their website: "Yii 2.0 is not ready for production use yet. It is currently under heavy development and we may introduce significant changes without prior notices. You may consider using Yii 2.0 if you just start to learn Yii or you do not have a tight project schedule."
They clearly are not encouraging using it in production in any way.
2.0 version is bet yet... because of this I suggest you to use 1.14 stable version ... in real project always better to use stable versions
there is available
Yii 1.1.15 is released (security fix) as well
The answer really depends on what the purpose of your Yii app is.
Are you building a quick demo? A throw away app? A 5 page app with no long-term maintainability needs? Go with Yii 1.1.15, it's very well documented and you will be able to work in a hurry.
Are you building a project with a minimum 3-5 year life? A web app that will see significant investment over the years? A web app that will have multiple developers involved in it? Go with Yii 2.0.
I've built large web apps with Yii 1.1.x and it works nicely. But for any significant new project, Yii 2.0 is a better fit. PHP as a language has progressed significantly since Yii 1.1 was designed and it shows.
In addition, development on Yii 1.1 is slowing down (the core team is more focused on Yii 2.0). I've for bug reports and pull requests for Yii 1.1 that have been outstanding for months. Not a slam on the core team (Yii 2.0 is where the future is), but Yii 1.1 is quickly going into maintenance mode.
I am leading a new project where we're convinced that MongoDB is the right choice for database. We have decided that the architecture would be SOA, so the web part will be developed using Symfony and the service part will be developed using light-weight REST framework Tonic.
Now, in the service part, we'll be communicating with MongoDB and for that, we have looked into a number of available MongoDB libraries: Doctrine MongoDB ODM, Mondango, ActiveMongo, MongoRecord, etc. However, we are not sure which one to pick.
I was wondering if anyone can share their experience with these libraries so that we can make the right choice. Here are some of the properties we consider the library should have:
Plain PHP classes for defining documents (instead of array/config files)
Support for references
Efficiency in operations
Easy to understand API
Looking forward to your views!
Personally I would go with Doctrine2 ODM. Seen as you have already decided on Symfony as your framework for doing the heavy lifting the pair are well aligned as far as I understand. You should be able to use this https://github.com/doctrine/DoctrineMongoDBBundle to integrate the two pretty quickly.
The doctrine setup ticks all the boxes you've set for your project goals and is fairly easy to get working with. Most importantly, it's an active project so bug fixes/features/documentation updates happen fairly regularly.
We use a similar setup, except zend framework instead of Symfony, and we're very happy with the results.
Hope this helps.
I would like to know about the compatibility between upcoming versions of KO3. I have heard that once 3.1 comes in, it won't be easy to simply upgrade to it from kohana 3.0 (Wordpress upgrade is pretty swift from 2 to version 3)
If I create my project in KO3 (currently using 3.0.6.2), what are the chances that my project will be easily upgradable to 3.1 or above versions without breaking anything ?
Please answer if you are a real pro on KO3 or part of the development team.. This is important.
Major versions (eg: 3.0 to 3.1) may change the API. Currently, the biggest API change will be splitting the Request class into Request and Response, as well as changes to Request that allow external routing. This also implies that the Remote class will be significantly modified to removed completely in favor of external requests and responses.
You can keep track of the changes scheduled for 3.1 by following the 3.1 roadmap.
I'd just like to point out that wordpress is an entirely different system, it's basically an application written on their own framework whereas kohana is just the framework and you supply the application.
If the wordpress core framework changes then they also change their application to account for those modifications. Sometimes plugins aren't compatible across upgrades so the plugin author has to release an update which makes it compatible. All of this is hidden from the front end users, they don't need to be aware of how it works in order to use it.
Kohana on the other hand has no gui or front end, you're getting nitty gritty with the code. If an interface changes then you'll have to adapt your implementation to suit, there's no way around that.
And as antpaw said, unit tests are always useful for making sure things work as expected! For more info see the unittest repo
it highly depends on the features your have used. give it a try and watch your logs or even better: you run unittests. http://github.com/kohana/core/compare/3.1...master if i picked the right repository. this will help you to see the difference betwenn ko3.1 and ko3.0.7