Basic Concept of Laravel Routing & Controlling without PHP knowledge - php

I want to learn practical knowledge so i directly go to laravel but i did not undertstand Basic Concept of Laravel Routing & Controlling without PHP knowledge, but i find php route content but confuse not concepts is clear about routing did not found any concept. I want to learn on very simple way.
I try hard to find simple concept of routing with and without parameters.

Routing in Laravel is simple ->
When HTTP request is coming to PHP application, for example:
GET /user/10 HTTP/1.1
FastCGI (or other servers) defines variable $_SERVER['REQUEST_URI'] with path /user/10; Laravel has only one entry point (index.php in public dir.) and to distinguish between which function we should invoke, Laravel checks that given path matches to defined routes in web.php (or api.php) file. Then, in matched route, we have information about controllers (set of functions). The controller is needed to share responsibility, so as not to write everything in one file. Routing and Controllers make up a well-extensible architecture.

Related

Lumen project structure

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.

Prevent Apigility from conflicting with routes from existing Zend Framework 2 projects

I have an existing Zend Framework 2 project. Now I've been experimenting and considering rebuilding the front end to be entirely AngularJS, as opposed to the now with Zend Framework 2 MvC coupled layouts and views. But for that reason, the models and controller with their respective routes exist and they use services that have a lot of business logic.
If I were to add an API to this existing project through Apigility, say, for external third parties to be able to access account information, how am I supposed to do that without interfering with my current controller routes?
Apigility Admin UI automaticly creates routes appending the base url (www.domain.com/[api url]). This does not directly conflict when I have an AccountController with /account routes and an API route that uses /accounts/[:accountId] but mistakes are bound to happen.
I should use a url like api.domain.com, however Apigility Admin UI adds the routes automaticly and has, as far as I have seen, no option to create a subdomain route through subdomain 'api'. Of course I could modify the automaticly generated routes every time I make changes through Admin UI but that seems like a hassle and prone to error.
While spreading my question around for an answer, someone on the #apigility IRC channel was friendly enough to give me an answer.
I was overthinking this, as dualmon mentioned in the comments. I had thought Apigilty Admin UI was a tool for managing the whole API. nuxwin^ on IRC told me that while Apigility Admin UI does automate routes for you which can be configured with a base url, it's still only meant for development time. It would mean if I were to route my subdomain to a module I could do that after developing the API.
Simple solution, I just had been overthinking that tool demanded me to follow a certain path.

Is it possible to have zend modules and non-zend side by side

We have a php based website we want to gradually migrate to zend framework. I imagined we could have three new components developed on the framework and the rest as they are in the old website.
Is it possible to achieve this only through sharing the session and filtering the http requests? In other words, if I request http://website.com?component=old_component then we serve the old website, and if http://website.com?component=new_zend_component we serve the framework? in each case the user's rights would be verified through the corresponding session information.
Or is it required the old website be under the framework's controller?
I think you can achieve this using apache/nginx/your server's rewrite rules. But if you have complex url structure it could be tricky.
If you'll go with controller maybe it is good idea to have just one default route for "old_components" and specific routes for new ones. But this is not really good approach since you'll be loading ZF + your old project, this will take longer to process than just using web servers rewrite rules.

Why route Restful requests through a .htaccess file vs a router (front controller)?

Backstory:
I am attempting build an API with REST architecture where performance is numero uno.
Team has experience with a solution (from a previous project) that routes all calls through an .htaccess file that then forwards to correct controller (.htaccess->controller(resource)->response). This is pretty fast, but the code isn't very flexible nor does it adhere to SOLID principles (overall I find it difficult to work with, plain and simple).
The current model is based off of http://coreymaynard.com/
Example:
.htaccess file:
RewriteRule api/logins/(.*)$ api/controllers/Logins.php?request=$1 [QSA,NC,L]
Controller:
logins->get_login; logins->post_login; etc etc. Extends a base class that reads the request and builds what method to execute.
I have been doing some serious research into API solutions and frameworks; Slim, Phalcon, Laravel, etc etc, with some basic (and mostly biased) performance testing for comparison with the adhoc system. The adhoc outperformed Slim and was neck to neck with Phalcon - we are not going with phalcon because it's not that well trusted within the team. So our solution is to write a minimal php application. I do not want to use the existing API system, and do something akin to a front controller.
I really like how Slim constructs resource routes, like so:
$app = new Slim/Slim();
//Add Get Route
$app->get('/my/route', Function/Map to Object/Do something else);
To me, this is readable, easy to maintain, and even easier to scale. Then I discovered this little gem on the web:
Small and Fast Controller with PHP
Based on these examples, I prototyped out a route controller and shared it with my team.
Questions:
1) What kind of performance hit am I going to see as I add additional routes? I haven't been satisfied with the information out there with executing routes this way (very procedural, stops handled by exceptions), nor do I have the experience to make assumptions.
2a) Am I being too cynical of the .htaccess method of routing? Is the server overhead generated for parsing an .htaccess file any real concern?
2b) Has anyone had experience building php applications or REST applications this way?
And as always, thank you for taking the time to read and respond.
UPDATE: We are moving to an Nginx server, meaning limited access to defining routes through Nginx's config and decided on a front controller to define our routes.
"UPDATE: We are moving to an Nginx server, meaning limited access to defining routes through Nginx's config and decided on a front controller to define our routes."
This screams to me that defining routes through .htaccess is ill advised. Your front controller should theoretically work on nginx or apache without modification, and your application would continue to operate as expected. I believe you've made the right decision.

Internal forward action in CodeIgniter

In Zend Framework, we can easily forward to an action in another controller using the _forward().
How to simulate this in CI? CI only have redirect but this is not I want, I don't want user to see the URL has changed in their browser.
Any idea to implement it?
I know for a fact that you can forward to another action inside the same controller without changing the url., with
$this->action();
Other than that, I do not see a built in way to access other controllers
This concept actually seems to break a more strict view of the MVC model, and this functionality you are trying to implement might be better suited for a library.
This sounds like HMVC (Hierarchical MHV) - i.e. controllers being able to load controllers without having to go through the HTTP interface again. You can install a package called Modular Extensions (by wiredesignz). Get the very latest from bitbucket, https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/overview.
Note that support for codeigniter V1.7 has been recently discontinued, so you'll need to user CI V2.0

Categories