It looks like the community is looking for ways to structure the domain layer of their applications and Eloquent just doesn't fit well. I suggest a nice and clean Doctrine integration as an alternative or replacement of Eloquent.

@TaylorOtwell I'd like to see:

• LDAP authorization driver. Something that integrates with FreeIPA.
• Symfony has Bundle, we might have Modules? We could install https://github.com/caffeinated/modules, but maybe you can think of some nicer integration.
• Basic web-app stuff like a Menu builder, Nested-sets, Breadcrumbs
• Maybe php artisan make:job?

haha - Doctrine is not going to replace Eloquent in Laravel.

And php artisan make:job is in 5.1.

I'd like to see Doctrine integration, not replacement for Entities Management.

@TaylorOtwell Now that external services are going to be part of our appliance more often(due to queue,pub/sub, lumen, jobs etc) we might need to have some helpers to help us. Like maybe:

• Build in CORSMiddleware? Now that Lumen is around, this might be a sensible thing to have.
• Option to have json output that is more hypermedia formatted? http://jsonapi.org/ Right now I use Transformers to do that( which is cool too).
• I recently had to deal with an API that I had to make a curl request to and gave me XML back. I used a repository, which I had decorated with a cacherepository. I couldn't illuminate\cache it, cause I needed to json_encode it first. No problem, but I didn't want to json_encode it..I just needed to cache it. So maybe we need find a way to handle XML from an external API in an way we treat incoming other data.

@TaylorOtwell , @JeffreyWay

Add Possibility to integrate client frameworks like : Angular , Riot.js , React.js More Quickly and with Logical way .

@sos99 What is a more logical way exactly? Our front-end team builds the front-end in total isolation from the framework. Then with custom build scripts, they add them to where we need them. We've got a very particular way to set up front-ends. Our Angular for example is made out of directives that are in the components folder. Every directive has it's own folder. Each directive has a template.tpl and scss etc. Then we have modules that are contextual bounded parts that live in their own directory. Also we have a separate folder for services. And because frontend can't wait on the backend, they will have a folder for data stubs. And folders for tests. A long with that, our frontenders have other scripts in other folders that do other optimalizations on the frontend. We do you gulp, but have loads of specialized extra's to do certain tasks.

Here is a printscreen of the angular components structure: http://screencloud.net/v/s1Dg

So what is more logical to you?

The only element I really wanted from the start was LTS and that is introduced in 5.1 so I am happy :P

Im just a newbie, but I wish I could use some kind of wildcard on contextual binding, like this:

$apiNames = [ 'youtube', 'twitter', 'tumblr'];
$this->app->when('App\DataSources\{apiNames}\{apiNames}Requester')
        ->needs('App\DataSources\Contracts\ApiManagerInterface')
        ->give('App\DataSources\{apiNames}\{apiNames}ApiManager');

or even better, without any variable declaration.

Helper classes and methods for building APIs as an official package might be a cool idea (something similar to the package dingo/api). It will save you a lot of time, so you can focus on the problem instead of building them yourself.

Obviously a need for a good basic acl is being asked for, and utilizing it through the Auth is a great idea.

Yes, actually many applications require tweaking, roles only assigned to users or no roles just permissions to users etc. But just as socialite and cashier have limitations out of the box, no package will ever fit every need.

I saw Entrust mentioned, it is by far the easiest package to work with and very simple (no knock on it) and to code the exact same thing in the root of your app takes less then an hour: Couple relationships, a couple of methods to check for a role or permission and done.

But with all the questions etc, something should be available imo from laravel.

Socket.io like functionality and most of all Skype Web SDK integration.

From: http://blog.thoughtstuff.co.uk/2015/04/skype-web-sdk/

"It works best in a MVVM (Model-View-ViewModel) environment, where it represents the model layer. It can be integrated with frameworks such as Angular and used in SPA (single page application) solutions."

Here's a good start for implementing ACL http://heera.it/laravel-5-0-acl-using-middleware . For lazy ones, i'm afraid you'll have to use heavy stuff like Entrust https://github.com/Zizaco/entrust .

sorry, @jartaud , but that argumentation is BS.
For almost everthing packages exits or it can be implemented by implemented by a user, depending on his skills.

The question was, what we like to see in L5.1 and obviously there's a big demand for ACL. And that has nothing to do whether the user is too lazy to write it by himself or not.

Following your argumentation we better all should start with eg LUMEN, or even better just put together our own framework:
http://fabien.potencier.org/article/50/create-your-own-framework-on-top-of-the-symfony2-components-part-1

Using frameworks, libraries, tools and other stuff that helps you build apps is not about being lazy, it's about focusing on the task / problem you have to solve with minimal time spent on reinventing the wheel.

For example, let's say that you have to build a hospital application for some client. The client won't care if you use Entrust or your own custom implementation, they want it to work the way they want it to work. The client doesn't care about the tools, frameworks, libraries you use.

i love the idea of ACL it would be great

i just finsihed implementing a custom acl with sentry2 thanks to that middleware tutorial.

Well @frezno keep dreaming buddy. Who needs ACL in the core when we have, middleware, middleware parameter? just a little creativity and bang. You can't just ask Taylor to code everything for you.

@Teranode Me too.

@Ruffles maybe you're right. But why do those people are wanting Taylor to reinvent the wheel when they could find some packages out there?

@jartaud true that.

But the ideas are nice. There is a post somewhere above where some person wants Skype SDK integration... Like what? :)

For most things there are packages to fix problems most of us will never use. I made a lot of sites where ACL for instance was not needed. Just a ROLES table and a USER_ROLES pivot and I was done. No problem. Stuff like that can be integrated very fast.

I'd like to see stuff that if smart and handy for an entire LTS release.

Let's be super compatible. I'd like to see an ever expanding list of all kinds of drivers( mail, auth, logging, queue, etc etc ).

ESI ? http://en.wikipedia.org/wiki/Edge_Side_Includes ..ah maybe not.. there is a package that can solve that. https://github.com/barryvdh/laravel-httpcache

@xsmall and by the end of the day the Laravel codebase would be just a copycat of wordpress.

@jartaud You mean with all the external packages? Or do you mean the actual core of the framework?

To what message are you replying?

@xmall with the well tested ones, no. But remember when Taylor decided to remove the Form and Html components from the core? it was like loosing a war. I think many guys are loosing the culture of using externals components. They just want all to stick in the core.

-Symfony2 has packages that are used A LOT, but are not official packages. They can be found on Github under the FriendsOfSymfony namespace. They are well known and trusted by a lot of users.

-PHP has packages that are good and trusted, which are no official packages. They can be found anywhere, but some people tried to grab the good ones and put them under one namespace.. The Php League

Right now there are 50 Laravel Menu packages, 100 auth packages, 40.000 role-management packages... WHERE WILL IT END?

Idea: @TaylorOtwell @JeffreyWay We have packalyst and it's very hard to pick the best packages or compare or trust. We don't know anything about the maintainers and for how long it is going to be maintained. And people..they might get ill or unable to work on them.

Would it be an idea to have an official League of Extraordinary Laravel Packages site?
Then the best Laravel packages with the highest quality from around the web can be put there for save keeping and maintenance.

This will allow for stuff to be included whenever somebody needs it. And it will be a good package.

@xsmall There's already a community called Laravel Collective which manages some of the official packages for Laravel which were originally part of the core but later removed.

@jartaud Why? Because there are a lot of packages and they have a different API or are being implemented differently. It would be nice to have an official package (it doesn't have to be part of the core, similar to Sociallite and Cashier). Zend Framework has an official ACL package (or it's part of the core) and I believe Yii2 and a few other frameworks have it too.

It is a useful thing, a lot of apps require it, so instead of using a package from the developer(s) you trust the most, everyone can use one and it will probably be covered on Laracasts. People will have a few lessons on how to use it.

Taylor doesn't have to reinvent the wheel, he can pick a good package and integrate it with the core. (or make it official)

Documentation Please!

Who needs ACL in the core when we have, middleware, middleware parameter? just a little creativity and bang.

@jartaud who needs Pagination, Swiftmailer, Stripe, Cloud, Templates etc in the core? just a little creativity and bang.

I totally agree with you that Laravel shouldn't become a bloated i-can-do-all-of-it framework.
But it would be nice to have a core for basic tasks and maybe a handfull packages with a high demand which can be added as needed/wanted as it's eg the case with HTML/Form

You can't just ask Taylor to code everything for you.

not at all.