I'm trying to comprehend the concept behind MVC and URL routing. I understand that it's good to seperate your code, hence MVC, but fail to understand the idea behind the URL router!
Instead of having a lot of rewrite rules in htaccess, I send all traffic to router.php, and in this page I have an array with page urls, and its corresponding PHP controller.
To keep it simple, I just include the controller, where the output finally is generated, however having seen lots of other practices, I'm afraid that im doing something wrong, or bad in some way..
Can someone please enlighten me, how to do a good, but simple URL router? Is it okay just to include the controller, which then generates the output? Perhaps someone has some information that describes the subject in details (something understandable for a beginner)
Thanks in advance
There are lots of ways to do URL routing. Some are client side like with backbone.js, others are server side. Doing it with .htaccess is one way, another is th way you are doing it by having a prerequisite path that is is either a hard path, or a regular expression that you parse and figure out where to send it. None of them are 100% right or 100% wrong, it's all preference, and it sounds like you are doing just fine with a route file.
For more information on how different frameworks do routing you should read over the docs on routing for CodeIgniter, and Symfony frameworks to see 2 different styles of server side routing, and then maybe look at the backbone.js framework for client side routing just to see the similarities and differences.
The router in the MVC concept decides which controller it has to load when a user requests a page. E.g. a user requests example.com/something/very/important, the router would now look for an action which is mapped to this route and execute it. There are different methods how you can accomplish that (simple include, instantiating a class and running a method etc.) but the most simple and still powerful solution I came up with is creating a separate class for every action. I've written a little article on that matter, since I've been asked this question several times, you can have a look at it here: Writing a simple and fast mvc router with PHP
The ASP.NET Routing module is responsible for mapping incoming browser requests to particular MVC controller actions.
Routing is a pattern matching system that monitor the incoming request and figure out what to do with that request. At runtime, Routing engine use the Route table for matching the incoming request's URL pattern against the URL patterns defined in the Route table. You can register one or more URL patterns to the Route table at Application_Start event.
Related
I want to build a Laravel application which users both web and API parts. The common (and mine as well) question is whether to use separate controllers or not.
There are 2 options:
Separate controllers
Laravel API controller structure?
Use one controller and check the request type (is Ajax, or depending on the request link) and return either JSON or HTML.
Laravel resource controllers for both API and non-API use
Those who have the 1-st opinion doesn't explain the DRY problem solution - web and API controllers would be the same except the return statement (JSON or HTML view). But since most post recommend to separate controllers I suspect I don't understand something about the DRY problem solution.
I don't see any disadvantage of the second method. But people say something like
If you use only one controller, you will end up soon with a messy class with thousands of lines. Not only this is not going to scale well, but it will be hard to work with for you and your teammates.
Please explain me the DRY problem solution for the first approach (separate controllers) and the possible underwater rocks in the second approach (single controller)
Please explain which approach is preferable.
I think this is a great question, and I too am keen to see the responses.
I can see the arguments for both approaches. I however would create and maintain separate controllers, whilst using services to share common logic between the controllers where it is known that this will never change.
For example, if you allow users to upload avatar images. I would put such logic in a service and consume this service in both controllers.
The reason for this approach in my mind, is that the web and API logic may diverge and it would therefore be easier to iterate each without impacting the other.
If this is unlikely, then I would still create separate routes, but point them both at the same controllers, so that if it did change in the future, you can simply re-point the API routes to their own controllers.
Is it possible to extend Yii URL routes and rules through a Controller on the fly, or by extending the CController class itself?
I am really stuck with this, have not tried anything.
How to do this in/with Yii?
First you should be aware of what URL rules are used for:
Parsing an incoming URL. The urlManager component resolves a URL to a route so that Yii can call the right action in a specific controller and module.
Creating URLs from calls to createUrl() in your code.
Considering (1) above it is obvious, that you can not add URL rules in your controller if you want to use these URLs in your application. It's much too late, as Yii already has gone through the process of resolving a request to a route. Even if you'd only wanted to create URLs it doesn't make much sense as your application will never understand them.
The correct way to bring more dynamics into your URL parsing/creation is to use a custom URL rule class. In there you can write any code you want to create and parse even the most complex URLs. The topic is described in the manual.
Seaside by default points example.com/myapp to whatever application is registered at myapp. I'd like to have a core application that can also handle these links, or some other way of handling these links.
So far, I have a home application that is also registered as the default application, so http://mydomain.com will resolve to it, but if I generate a link, like http://mydomain.com/more-info, Seaside tries to resolve an application registered at more-info. What if I want my home application to handle the link? Or handle it in some other way?
I'm hosting Seaside with Apache, so I could use Apache's URL rewriting engine to rewrite http://mydomain.com/more-info to http://mydomain.com/home/more-info, which would be handled by my home app.
Is there a better way to do this? Also, if a link exists to an explanation of the Seaside request/response lifecycle, that'd be sweet.
What you are trying to do is not common practice in Seaside applications. If you want to generate a link from one page to another page in your application, you generally use a callback attached to an anchor:
html anchor callback: [ self call: moreInfoComponent]
In such cases, you do not care about how the url looks like and Seaside generates the url for you. Such generated urls never have a nested structure but use parameters.
More information on the Seaside request/response cycle can be found in the online book (chapters "Fundamentals" and "Sequencing Components").
However, if you indeed want to have such a nested url (to make urls bookmarkable), there are different approaches, depending on what you actually want to achieve. You can either take a look at the approach for handling expired sessions (in the book) or at the Seaside-REST package.
Btw, the mapping of urls to applications happens through (instances of) WADispatcher. If you inspect the result of the following expression, you can see the dispatcher tree of Seaside. It's entirely customizable by adding new applications, dispatchers, etc...
WAAdmin defaultServerManager adaptors first requestHandler
Hope this helps you on your way...
I'm from a non-computing background and I'm struggling to getting my head around MVC design approaches and frameworks in general. I "get" code re-use, and separation of logic from display, and I "get" encapsulation and decoupling, but I don't get this.
At the moment I simply put everything in root, a separate subfolders for images, cfcs, and _includes, all database interaction via cfcs. I do all my processing at the top of the page, then a comment line then display/page layout below that.
Most of the frameworks I have looked at seem to favour a front controller, so my simplistic version of a top controller MVC design would be a subfolder for cfcs, controllers, and views and a big switch statement in index.cfm
<cfif not IsDefined("URL.event")>
<cflocation url="index.cfm?event=home" addtoken="No">
</cfif>
<cfswitch expression="#url.event#">
<cfcase value="home">
<cfinclude template="controllers/home.cfm"/>
<cfinclude template="views/home.cfm"/>
</cfcase>
<cfcase value="about">
<cfinclude template="controllers/about.cfm"/>
<cfinclude template="views/about.cfm"/>
</cfcase>
</cfswitch>
.. but what real advantage does that give me over a page controller design? Unless it's just the kind of sites I write, I always seem to find that the controller logic is specific to a view, its not like one controller could fit several views or several controllers could output to one view, so what would be the point of separating them?
The light hasn't come on for me yet, any pointers?
By "top" controller, I think you mean "front" controller, a single point of entry for requests into an application. As #bpanulla wrote, most ColdFusion frameworks use this design pattern. This becomes particularly interesting with URL rewriting, where it becomes easy to have search engine safe URLs by intercepting the a URL (e.g. domain.ext/i/am/friendly.ext) and routing it to some standard file such as index.cfm while making the requested URL a parameter (often as a request header). This also makes site redesigns where URLs change easier because it lends itself well to aliasing or redirects.
As far as controllers are concerned, they are usually tightly coupled to a particular URL or URL pattern. It's possible be more loosely coupled with controllers, but in practice I find that's an emergent property after multiple refactorings. What should be underlying the controller is one or more calls to a service layer that talks to the database, executes business process, creates stateful entities, etc... Then the controller receives the service layer's outputs and places them into whatever mechanism (e.g. an event object) is used to pass data to the view(s).
It's the service layer that's meant to be reusuable not the controllers. The controllers are merely an extension of whatever framework an application works within. The idea being that you should be able to switch frameworks with very little impact to the views and service layer. The piece that needs to be touched are the controllers.
So a given service object in a service layer should be able to service multiple controllers. For example, consider showing a logged in users' information as a widget on a site. There might be different pages served by different controllers, but each would call the same service object to get logged in user data that presumably might be given to the same view that renders the widget.
Update: Front Controller Advantages
Security: centralized authentication and authorization.
i18n & l10n: inject the right language pack into the request globally
Process Orchestration: think multi step checkout process for a shopping cart where you don't want the back and forward buttons to work - by routing everything through the front controller you're able to enforce what step (i.e. the state)
Logging & Tracking: easily add Google Analytics or other request tracking to a site by making the addition in just one place
Error Handling: centralized behavior
Now many of these items can also be done using <cferror> and Appplication.cfc, but I find it easier to have one centralized point.
Useful Links
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
http://msdn.microsoft.com/en-us/library/ff648617.aspx
You actually implemented the crux of Fusebox (http://www.fusebox.org/) with what you wrote. There's nothing wrong with that, and most of the ColdFusion community used something similar to that for many years - Fusebox was the most-used CF framework (in my experience) until just a few years ago when ModelGlue, Mach-II and the other second generation CF frameworks came about.
One thing I can point out is that your approach to controllers (as .cfm files) actually does not enforce encapsulation in the typical OOD fashion, with specific arguments going to an object method call. Unless you are extremely dilligent, over time your .cfm controllers may wind up accumulated a large number of undocumented parameters that alter behavior to solve one problem or another.
With the various frameworks you also get nice features like Application, Session, and Request specific code (onApplicationStart, onRequestEnd, etc). But you can always get those through a simple Application.cfc.
When you're making a web app, you frequently need different things to happen at a given URL for HTTP POST requests than happen for HTTP GET requests. I am making a web app in Pylons, and I'm encountering this question.
Is it better to distinguish between POST and GET in my URL dispatcher (Routes) or in my controllers? What factors would make one of these options better than the other?
Would the answer be different if I were using Django? Rails? ASP.NET MVC?
Good code should have clean separation of responsibility therefore the routing/dispatching code should control where I request is sent. This is just good design and shouldn't change because of the language.
A reader of the code can tell just from reading the routing code what is expected and where it will go. If you change your mind later on, you can changing the routing code without touching the controllers.
The controller is then only responsibile for handling the request which makes it simpler, making it easier to understand, have fewer bugs and easier to change.