I'm trying to implement url routes into my own mvc framework and I like to find out the best way to do it. I'm thinking three solutions.
Make a XML file and read it in my frontend controller then load the matching controller.
Make a table that stores routes then execute a query in my frontend controller then load the matching controller.
use either xml or table and then load routes into memcache then use it.
my concern for #1 and #2 is that I have to read a table or xml for the every access.
my concern for #3 is that not all the hosting companies support memcache.
Any suggestions would be appreciated!
Added: I think I confused some people. By 'route', I'm actually talking about rewriting...like...I want to rewrite visitors to '/controller/action' when they visit '/hello'
Thanks
I would not use XML or tables for this. This will require additional resources for such (in comparison) easy operation. You should have a script which is loaded by mod_rewrite, it parses the URL, loads the proper controller and executes the action.
Hey I know this is a little late, but please check out my Routes class. I know you may not need it now, but hopefully it will still be useful to others.
With this you could easily do exactly what you need to with simple syntax and rules. All you need is to break down the parts of the returned URL (from a Routes::route() call) to calculate your controller and action method (and any possible parameters).
The reason this routing library doesn't do that for you is because you may not be in an MVC world when using it, but it's not that difficult to create. Because it's so low-level you could even create routes dynamically, say from a database table or memcache.
I think I can re-phase and even generalize the problem:
You want to create a representation for something (in this case URL
routes) that are easily human readable (eg, XML);
You might also like that this representation can be easily
computer-generated (eg, from a database table);
At run-time you don't want the solution to be slow: eg, parsing a
large XML file, reading from disk, or fetching rows from a database.
You don't know what caching solution will be available in a
production environment.
So you should aim to:
Perform the slow operations (reading from a database, parsing XML) as
little as possible - perhaps in a compile or build phase, or "on
first run".
Perform the route matching in a fast way: compile the rules directly
into PHP code, and execute them as regular expressions or some such.
Cache the rule code as a php file and include it as regular code. APC
is a php code cache that is commonly available in all production
environments.
This would lead me to implement a solution with the following classes and methods:
Router::addRoute(pattern, controller) - adds a route
Router::match(uri) - returns matching controller
You can store routes in whatever format you fancy (XML, Json, in a database), and generate a simple PHP include file to load routes quickly at runtime:
<?php
// compiled_routes.php
$router = new Router();
$router->addRoute('/', 'HomeController');
$router->addRoute('/widgets', 'WidgetsController');
tl;dr: separate the route rule-parsing from the route matching. Perform rule-parsing only once, and compile the result into PHP code which can be cached by APC.
Hope that helps.
Related
I'm fairly new to Codeigniter as well as MVC and I'm having a bit of trouble figuring out the best way to accomplish this.
I need to build an app that allows users to apply to various programs offered by some institutions. However, these institutions must all have a spot in the app yet they want their independence from one another—not sharing one application page for all programs. For instance Institution 1 wants a section of the site to only view and apply to their programs and Institution 2 wants a section of the site to only apply to their programs.
What is the best way to accomplish this? Should I create a separate controller for each institution?
E.g. sitename.com/inst1/apply, sitename.com/inst2/apply
Each of these controllers would essentially be identical with the same create/read/update/etc functions though. What are best practices in this situation? Thank you!
You can create folders to serve your functionality properly. This is widely used for APIs.
For example. You can have your folder structure like this.
- application/
- controllers/
- inst1/
apply.php
- inst2/
apply.php
With this, you'll have the URL endpoints like.
index.php/inst1/apply
index.php/inst2/apply
I think you have it right, you'd create controllers for each institution allowing you to change what data you were pulling for each. The views could be shared since all the functionality would be in the controller/model which is one of the more important aspects of MVC to begin with, the ability to separate those layers and reuse what you need where you need without duplication. If you set up your pages as a template you could even pull different templates to feed the views to that would be institution specific.
For this you probably want to use the same controller and instead handle the variation through passing your function a different uri segment which you can read about here
. In my codeigniter applications i like to keep a specific functionality within each controller or model. So it might look something like:
sitename.com/my_controller/my_function/my_argument
Where the function in your controller looks like:
public function my_function($argument){
//stuff goes here
}
You can of course use your routes file to make the url look however you'd like.
Just build a single controller, and make a flag to differ them. In the view file you may check for this flag to decide weather to show programs and apply or not.
Your url would be like that:
sitename.com/inst/1/apply, sitename.com/inst/2/apply
note: you may also change the numbers in the url with words; to better seo.
I am working with Codeignitor 2.x and I was originally using controllers as modules (though not completely HMVC), in that I had a Top Level controller that would call other lower level controllers. My thinking was that because these lower level controllers were still interacting with the view, that they should remain controllers rather than models or drivers.
What I found, however, is that each instance of a controller also spawns a new instance of CI. So I would have 3 or 4 instances of CI running for each request. Ton of overhead, and also caused session issues.
I have since moved these lower level controllers into the library as drivers. They now capture the CI instance in the construct method, and make modifications to it. This makes it VERY nice to work with, and doesn't require the HMVC extension. The drivers are not externally callable either, so it allows me to funnel all requests through specific entry points.
My question is whether this is structurally correct. I have always held the notion that drivers should only modify the data they are provided through their method calls, but many of these drivers will pull information directly from GET and POST, and while they will not directly append to the View, they are often accessing view files, and passing the processed view to the CI instance for output.
[EDIT] A little more context:
One of the drivers I have created is essentially a user login driver called 'Access'. It makes calls to the 'User' model for create/login/logout methods. The driver uses the POST data to check the User model, then loads the correct view with errors and whatever is needed. The idea, being, with 2 lines, I can include this driver in any controller throughout the project, so there is a significant decrease in code redundancy. Again, I know that the drivers should be confined to their scope, however the driver does not modify anything outside it's scope, but simply returns the view it has created.
Is there another method to for doing this that is more inline with straight MVC?
I can't say whether it is right or wrong. But if I were you, I wouldn't do that. I'd probably refactor some of the code. I'd make sure that they don't grab and manipulate data directly from the $_GET or $_POST superglobals. Instead, pass in some data as arguments to a function call. This would make testing easier, since you don't have to simulate a GET or a POST request. While technically, you could just set the value for the superglobals manually from the code, but I'd not recommend doing that. Supplying data as arguments would be much better, especially if you want to write test cases that are to be executed subsequently. Plus, having the libraries interacting with the scopes beyond its own might introduce some hidden gotchas.
In my opinion, libraries are meant to be something like modules, where you can just drag and drop, and then use them without any hassle. If your code really needs to grab or manipulate values from $_GET or $_POST, maybe they are meant to be models instead. Also, you might want to think whether your code is actually a library or not. Ask yourself, will this code be useful outside this application? Or is it highly dependent and can only be useful for this particular app? If you say yes to the latter, then it's probably should be a model instead of a library. Last thing, you should leave the views to the controller. Just return the data you need from the library/model method then pass it to the view from the controller.
I'm using the front controller pattern in conjunction with a command resolver class, whose only function is to map requests from the view to a command object.
Everything works fine, but I'm starting to wonder if my implementation, which basically consists of a switch statement, is actually bad practice.
Would it be better practice to replace this switch statement with an XML file, or to map the requests physically to files in the command class (i.e. the request name would be the file name), or is a switch statement fine for this purpose?
Edit: I am using MVC, the front controller exists in the controller. This is more of a design pattern within a design pattern question.
Front Controller needs a router class, often used along with MVC design pattern.
To see how you can avoid switch, see this nice tutorial at phpro.org:
http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
Here is how the router is constructed in above tutorial.
By using switch, you are hardcoding a lot. How about writting command function which will check possible array of files (possibly from cache which will be filled once by reading directory with files), and load a file if its ok.?
I'm adding an API to a Symfony-application which should act as a REST web-service. But there are a few open issues.
Different URIs for bots?
I often read the "suggestion" to use URIs like /api/:id/[...], but I think they wouldn't be REST-compliant: No matter whether bot or human - the same unique resource is identified.
I'm asking, since my statement above makes sense, but I don't expect all the others to be at fault.
Modifying existing controllers?
There are several reasons why I need a separate controller-logic for both cases:
No session-login in the case of a api-requests
different Symfony-forms have to be created (For instance, no widgets are required, at all.)
JSON / XML instead of HTML output
I don't want to modify existing controllers. According to the Open-Closed Principle, classes should be open for extension but closed for modifications, and the controller classes are already in use in a "production"-environment.
My idea is to use an extra HTTP header-field (e.g. "X-UseApi"). The routing should call different actions by evaluating it. Is this possible inside routing.yml? How? Do you have other ideas?
Authentication
This is how I implemented bot-authentication:
$user = Doctrine_Core::getTable('sfGuardUser')->findOneByUsername($params['user']);
if($user->checkPassword($params['password']))
{
//...
}
But the code looks like a workaround to my eyes. Are there better solutions for the whole REST authentication issue? Is the sfGuardPlugin / sfDoctrineGuardPlugin not meeting conditions for such use cases?
Thanks in advance and cheers,
fishbone
my way of doing this would be to use sf_format in routes to distinguish between robot and human (robot will probably need to consume XML whereas human will want HTML.
I would alter my controllers in a way that I would delegate the logic to separate classes depending on what format is requested (this shouldn't be too much work and you would get the flexibility you need).
As for authentication - please provide a bit more information on how do you do it now - the example isn't enough for me to get the general idea of how your implementation works.
Different URIs for bots?
I suggest to not worry too much about URIs. There are more problems with them and thinking too much about it just results in losing time. IMHO it would be great if there would be standardized conventions how to define RESTful URIs. Here is an article about it: http://redrata.com/restful-uri-design/ . You can see that every way of designing your uris has its pros and cons.
But today I would reject the statement that 'api/...' isn't REST compliant. I would just avoid it.
Controller and authentication
Finally, my solution was to implement some sfFilters with responsibilities as follows:
ApiAccessFilter: sets request-attribute 'isApiRequest' if X-ApiKey is defined as header field.
ApiKeyAuthFilter: identifies a user by X-ApiKey, calls signIn / forwards to login-action.
SecureApiAccessFilter: Checks whether the current user has credential
'apiWriteAccess', if HTTP-method is POST, PUT or DELETE.
The first filter allows me to call $request->getAttribute('isApiRequest') later in my actions. That's similar to isXmlHttpRequest(). Finally I came to the conclusion that I have to modify existing actions, because requirements have changed due to the web-service extension.
Cheers, fishbone
I am working on code re-factoring of configuration file loading part in PHP. Earlier I was using multiple 'ini' files but now I plan to go for single XML file which will be containing all configuration details of the project. Problem is, if somebody wants configuration file in ini or DB or anything else and not the default one (in this case XML), my code should handle that part.
If somebody wants to go for other configuration option like ini, he will have to create ini file similar to my XML configuration file and my configuration manager should take care everything like parsing, storing in cache. For that I need a mechanism lets say proper interface for my configuration data where the underlying data store can be anything( XML, DB, ini etc) also I don't want it to be dependent on these underlying store and anytime in future this should be extensible to other file formats.
Assuming you're wanting to use a class to handle all this, you have 3 options:
Have a base class called something like, ReadConfigurationBase then 3 implementation classes, ReadConfigurationXML, ReadConfigurationINI, and ReadConfigurationDatabase and you'd have to choose the right one
Same as above, but using a factory to choose, based off of something passed in. Like if you pass config.xml it would know to return ReadConfigurationBase implemented using ReadConfigurationXML
Have a class called ReadConfiguration and it acts as step 2, but creates, contains, and owns, the 3 other classes.
The 3 non-base classes would simply know how to read that type of configuration file, and pass the information back in a generic manner. think along the lines of an interface: You know you can get the data, but you don't care how.
I'd suggest option 3, since it would make life easiest. You would have to do a little bit of modification every time you want to add a storage method, but that would just be adding a little bit into the ReadConfiguration class.
There is a way you could make it 100% dynamic, but that would complicate matters, and I don't think you really need it for this.
Have a look at Zend_Config. It provides adapters for Arrays, Xml and Inis. Like all components in Zend Framework, it can be used isolated from the remaining Framework. Even if you don't want to use it, it's well designed and you might get a few ideas for your own config manager from it.