I am making a controller for each type of request post/put/get.
So my question now is, what is the best way to put controllers in subfolders when using L 4.2 ?
/controllers/subfolders..
I've seen some people using namespacing and some people simply makes a subfolder and put their controllers in it then run composer dump autoload-
But is there any "best practice" way to do it in L 4.2?
I do it the namespace way. One advantage this gives is that we can have same named classes inside the folders. Currently in a Laravel 4.2 app that I'm building, I am using controllers/api subfolder, with the namespace of Api for all the classes in it. And one of the classes is UsersController. Which might also be used for the frontend website, so now you will have to say FrontendUsersController, or something weird and long. So to avoid this, better get in shape with namespaced controllers.
Also, Laravel 5 advocates namespacing for your project, so does PSR standard. So this is probably much better way in the long run.
Related
I'm beginner at Lumen (and php) and I am a bit confused all the structure as the only people I talked about Lumen to were interns just like me. I created a project where I use Models where all my methods and functions are, I have constructor in my controller class where I call functions from class Model.php and then pass that to view.blade.php (in resources folder) where all my html goes. I return view from controller. My question, is that correct? Should I have class for view? If my structure is not correct, how should it look? What correct sequence of passing information should be then?
Thank you in advance for claryfing it for me :)
I know MVC structure should be similar to .NET but still I am confused somehow.
You should not use Lumen for a fully-fledged application with HTML views, assets, etcetera.
Lumen is a microframework specifically designed to build APIs in a lightweight environment, which allows you to focus entirely on the resources to serve, instead of the design.
Lumen is way faster compared to Laravel, for example the Routing is handled by FastRoute instead of Illuminate Routing, which is quicker and lighter for the application.
Use Laravel for what you are trying to do.
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 have an interesting question regarding Laravel.
I am building a control panel with certain functionality with Laravel 5.
This control panel will work standalone in a subdirectory of any another PHP website.
Here is how the folders tree looks like:
/index.php
/(other php files from the main project)
/controlpanel (Laravel)
I want to use the Laravel functionality within the main PHP project.
For example I want to be able to query the database of the control panel with Eloquent models from within /index.php.
Something like limited Laravel (without routers, etc).
I have tried to include the bootstrap/autoload.php and call Eloquent model, but the IoC Container is not instantiated and it's not working.
I hope someone can point me to the right direction.
You can use some of Laravel's packages outside the framework, however it takes some doing in most cases.
Laravel Illuminate Router Package In Your Application
Use Eloquent Outside of Laravel
The resources above are for Laravel 4, but you could use them as a starting point as they might be very similar to the approach needed for Laravel 5 packages.
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.
Is there a way to use Doctrine using the model classes I've already setup for my Symfony applications without having to call Symfony with all that overhead?
This is more to satisfy a curiosity than anything else. For all the scripts I've used, I've just been able to instantiate Symfony (which typically turns out nice since I have all of the features that I'm used to working with on this particular project. But there has to be a way to load Doctrine and use the Symfony model classes without Symfony... Right?
Doctrine isn't dependet on symfony. Doctrine is a "framework" on its own. It has it's own autoloading and can therefore work with it's classes like a regular PHP app. You can integrate Doctrine with other frameworks if you want (like CodeIgniter or Zend). So you have every freedom you need without the need to do some tedious migration of your models/data/... from one system to another.
I've come to the conclusion there really isn't a way to use the model classes from Symfony elsewhere. With a little work, you can port over the classes to a new Doctrine model (even if you use the generator, since the main model class just extends the base which extends sfDoctrineRecord (from the API docs, you can see which functions will need to be removed).
Otherwise, there isn't a practical way of doing that.
Anytime I need to access the Symfony model, I'm making a task or plugin since I do typically need part of Symfony's functionality.
As far as Symfony2 goes, just looking at the documentation makes me want to run screaming. It's not mature in any form or fashion (but, then again, neither is Symfony "legacy"). So, I'm not sure if the process would be any easier there.