I'm studying the Laravel 3, 1 week ago, but didn't understand everything about the routes.
My main question is: how to create administrative routes?
In the video lessons from Jeffrey Way (Tuts Premium), I could understand two things about it:
Nested Controllers (/application/controllers/admin/user.php)
Bundles (/bundles/user.php) - He did not say much about it.
Anyway, I noticed 2 things (obvious):
On both sides, I can have a route / admin / whatever.
But what the correct way?
I'm really very confused.
Laravel bundles are for developing modular code that you can reuse from application to application in Laravel. The Bundle itself is very much the same as the 'application' directory you have as standard in a Laravel install, allowing you to create modular sub applications within your project. I highly recommend you avoid bundles for the moment entirely and focus on learning the core functionality of Laravel.
For your needs, place your routes within your routes.php file within the application directory and nest them to your hearts content. This will serve your purposes fine. If you're not building/using bundles, you don't need to use bundle routes.
When you're comfortable with Laravels routing and you've built one or two apps you may well have an idea for a bundle that will help you develop your apps faster in the future. This is the time to start learning about bundle routing as it's the only way to link your application logic with your bundle and provide it with a URL schema.
Hope that helps.
Neither way is really right or wrong, the beauty of Laravel is that there are so many ways to achieve the same thing so it's up to the developer to choose what works for them.
Personally I started by using nested controllers as they're much easier to get up and running. I would however recommend making the move to bundles. If you plan on sticking with Laravel (and you should) then it would make sense to build a bundle that includes the auth and components you use in each project already setup. That way you just need install the bundle and you're good to go.
Related
I've made an online store in php for school, and now my teacher wants this project to have a Laravel Framework. And I have no freaking idea how to do it. Are there any possibilities to implement this framework to my project, or my project to this framework, without starting from scratch? If yes, how should I do it?
irrespective, its going to involve a lot of rework. A lot also comes to down to HOW you've developed your original php app. Laravel is a Model View Controller framework. For starters all your routes (http redirects) are generally managed in a single file (web.php). Your views can be traditional php, however, Laravel gives you a good templating engine called Blade which allows you to shorthand code and keep code a lot cleaner. Models control your table relationships, controllers handle the functions/code/crud etc.
You will love how easy it is in most respects - especially the way eloquent data queries work etc. It can greatly reduce your code.
If your teacher wants you to LEARN Laravel specifically, I would say YES you will be starting over - however, your logic in the code should just need reworking rather than start from scratch.
There are heaps of posts around HOW to install Laravel (apache, virtual box, homestead etc) - once your ready, its super simple to create a new project and start building away... If you are new to MVC, you should do some tutorials first (e.g. laracasts or other).
Best of luck :)
Problem:
I’m unsure how to set up multi client application for Symfony so that we would not violate Symfony's best practices and work against the framework.
I would like to have one main Core namespace which would contain all the base model classes. Right next to the core I would like to set up client specific namespaces which would be used, based on client regional setting. For example LocalUS for US market, LocalUK, for UK market etc.
The Local* namespaces should take first priority for including twig templates, and as a fallback use core common shared views (as I understand, this is solvable via twig namespaces). Same goes for controllers and models - these are probably solvable via extending the Core namespaced classes? Is this all solvable via routing and providing paths for these Local* controllers?
I was looking up on github to see if there are any project that have similar setup but I couldn’t find anything.
A little background:
We have an older legacy PHP Application which was built in-house from ground up using plain PHP. As the application has grown over time, it has become hard to maintain good code quality and standards. It’s also very time consuming to teach new developers our application logic, since the application basically follows no standard design patterns and just does it’s own thing. A lot of the underlying code which handles routes, controllers etc seems to work like “magic” that nobody really dares to touch.
It is because of that we would like to migrate our application to Symfony3 framework. I’ve read some articles about the overall process of migrating legacy applications to symfony, and managed to do it with silex pretty well. Silex, however is a bit too lightweight, I found that the assetic service provider had a lot of functionality missing (twig namespacing etc), and decided it would be best if we could move to a full stack symfony framework instead.
Look into Symfony bundles - they do exactly what you need. You create a "base" bundle, than extend it with other bundles. That's how FOSUserBundle works - it provides everything you need, than you extend it and overwrite it.
I have a very old flat PHP project. I would like to modernize the source files without changing the big and old database structure. I found the PHP Framework Symfony Silex. I like the micro structure of this framework it's not so complicated to understand.
I have the following file structure:
- classes (The business logic)
- web (index.php and all my controllers)
- vendors
How can I include my business logic from the Silex app? Should I use require_once('classes/file1.php'); in my index.php?
How can I access the database from the business logic files?
Transitioning legacy code to a new framework is a difficult task. It's not going to be as simple as requiring your business logic files. Here's how I would go about it if I were in your position.
Spend some time learning Silex. Start by building a brand new test project with it to see how it works. It's best if you know how the framework is supposed to work before you try to integrate it with a legacy system. After you've tried it for a while, you can decide if Silex is a good fit for you.
Once you know how Silex works, you should get the Composer autoloader working with your code. Composer can load you business logic classes without having to use require.
Next, figure out how to work with your database. I see two options for you. You can either transition to Doctrine, or use your existing database access classes. The Symfony (and therefore Silex) ecosystem is oriented around the Doctrine ORM. Depending on your schema, you may be able to write Doctrine mappings for it. However, Silex is not tied to Doctrine, and you should be able to use your existing database access code. If you keep your existing system, you'll probably want to write a Silex ServiceProvider to integrate with it.
Next, the hardest part is probably going to be moving your business logic to Silex controllers. One thing to keep in mind is that you don't necessarily need to transition your entire project at once. Depending on how big your project is, you may want to transition a piece at a time.
I'm new to Symfony and am starting an app which includes an admin section. The general advice is pretty obvious - make an AdminBundle.
However, is that really the best practice? The Symfony documentation is saying that a bundle is intended to be a 'plugin' that can be distributed as is, and will work in another app. Doesn't the admin section need to be aware of all the models and things for the main app though? It's an admin section created to administer changes specifically to my app, so how would it be distributable or self-contained?
I feel like I'm missing something because if all the advice is to make an AdminBundle then I obviously don't understand something or haven't delved far enough into Symfony yet.
I'm just looking to get my app started with the correct structure going forward.
FYI, I created a project with the default AppBundle as well. I was just planning to make everything in there, but that doesn't seem right either as it will be harder to organise all the admin stuff separately.
I think it depeneds on tour needs and size of your project. Creating a special bundle to put there logic for of admin panel is a good practice. But if you have a small application with just couple of entities it's not necessary to create AdminBundle.
Symfony provides you any way you prefer to do what you need. You can create bundle or put all the admin panel business logic into special directory inside your main bundle controller directory or put all code into the same controllers and manage permissions to admin actions by setting up firewall.
I would suggest to use AdminBundle. It lets you keep your code cleaner: a client logic in one bundle, an admin logic is in another.
Bundle description taken from symfony official documentation isn't saying any opposite things. Because if you want you can use your AdminBundle in another app. Bundle is a way to keep different kind of business logic separated of each other.
I have an application which is developed in Symfony2. Now the structure for it is as follows:
FrontBundle - includes everything related to the application's view and UI.
PersistanceBundle - includes everything related to the persistence layer of the application.
DomainBundle - includes everything related to the entities of the application and the services.
Is this structure ok? Or bundles are used like forum feature - ForumBundle - which includes every layer (controllers, services, domain logic and persistence) related to the forum.
There are no hard and fast rules on how to structure your app using bundles, but here's what I came to after developing on Symfony2 for close to a year.
Use one app specific bundle. At first, I started with multiple bundles like CommonBundle, UserBundle, MainBundle, BlogBundle, ContactBundle, etc. That proved to be not so convenient in the end, so I switched to just one app specific bundle — AppBundle.
You can organize your code neatly using subnamespaces. For example, the backend controllers would go to the AppBundle\Controller\Backend subnamespace.
Note that I'm talking about one app specific bundle — that stuff that's unique to the concrete app and won't make sense to reuse elsewhere. You can still develop separate bundles for reusable stuff and put them into the vendors infrastructure.
Keep non Symfony specific stuff out of bundles. There is no need to have a bundle for the model and the Service Layer classes in a bundle if they are not Symfony2 specific. See this question and my answer for further details.
Like Elnur said, use one AppBundle is a good practice.
A single bundle implements the MVC pattern himself so i think it's not a good idea to use bundles to separate your layers.
I think the best way to use bundles is to think "open source". If the feature you are developping is enough generic to be released for everyone, or to be reused in a future project, place this feature in a bundle.
This way will force you to build the feature without any business rule which belong in your AppBundle.
Bundles are bricks
There are different ways to organise application structure for your projects. But if you want to distribute your bundles and follow symfony best practices, then bundles are more features than separation of UI. More about bundles read in documentation.
I have two projects with the following structures, both valid I think:
making a bundle for each feature: BlogBundle, StoreBundle and so on,
and AppBundle that contains general stuff. No Backend/Frontend
separation. It's SaaS where backend is frontend in most cases.
One bundle for frontend, one for backend. They share only entities
and domain specific stuff. The application has two different ends.