I have a model Project which have many Orders. On the page of the project, I have a list of its orders and create/update buttons.
Now I pass project_id in GET params in url. I need watching that each url and redirect have this parameter (in the update and create views/controllers and in the list of orders view/controller).
Is there a better way, to pass parameter through views and controllers?
This doesn't really have anything to do with MVC. In a web context, each HTTP request must be self-contained. All the information your server needs to fulfil the request must be contained within the request. Either within the URL, or within the request body.*
Whenever your server generates a URL somewhere to send back to the client, you need to embed all the information necessary in that URL so a request made to that URL gives your controller all the information it needs to fulfil the request. So, yes, you'll need to pass all the information through to that place in your code. That's pretty much the same whether you use MVC or plain spaghetti PHP files.
The only alternative is for you to reduce the amount of information the controller needs to fulfil the request, e.g. because you can implicitly get one part of information from another, like the project id when given just an order id.
* (I'll forego something like session storage here, since that's stateful across all requests and generally cannot be used for transporting information specific to individual requests.)
Related
We have a CORS REST API. It's clean. It works. It's almost perfect. But...
I'm trying to implement an endpoint with request specific parameters. This endpoint should accept POST, PUT, LINK and DELETE requests. And I'm not sure how to implement these parameters.
An example:
A user wants to DELETE a model. There are two scenario's: one where the model is deleted and nothing else happens, and one where the model is deleted + a notification email is sent out.
Initially I implemented this parameter in a header called "X-NOTIFY-OWNER". This worked since it could be added to any of the 4 actions. But now we'd like to get rid of that header, since it's too specific to this single endpoint.
What whould be the best place to put this parameter? A query parameter sounds cleanest (since DELETE and LINK technically don't need a body), but query parameters should be used to filter content. A parameter in the request body would work too, and seems to be the prefered method; but it means sending a body with the DELETE and LINK actions...
Any thoughts on best practice in this case?
I would stick to a query string, DELETE is supposed to ignore the body and only read the URL so it makes sense to use a query string here.
You should use an URL parameter. As you stated, they should be used to filter output and an e-mail can be considered to be output.
I would recommend setting up a new endpoint for the cleanest solution.
example.com/endpoint
example.com/endpointAndNotify
You could either:
Setup the notify endpoint to extend the base endpoint and then add the notification logic to the notify action.
Abstract out the shared logic from both actions, update each action to extend the base class and then add the specific notification logic to the notify action
This way both endpoints stay clean and concise and if you define a standard for this endpoint, any other endpoints that need notification logic can use the same standard.
Session is retrieved in SF2 through the Request object. Hmm, this becomes kind of problematical when some architecture is considered - in cases where access to a session vars is needed from within a service.
Or perhaps, I'm not quite correct in this matter? (Hope so).
Obviously each request from a user through a webbrowser is a Request. So as long as we use controller actions in standard SF2, we have Request. But should we then pass the Request object to any service we need?
Passing Request object to all of the services that needs their methods to be run (e.g. storing info, checking settings, putting filters for displaying data etc. - well in some bigger apps it's quite a lot of them!) because it might be needed because of the dependent services, seems to be a very stupid idea to me. It also breaks the "S" in S.O.L.I.D. recommendation for OOP.
So I came up to a conclusion I need either to:
Pass the Request obj to many services just because the dependant service might need some data from it (i.e. broken "S" as above)
Retrieve and process data from Request every time I needed in every single controller action (i.e. code duplication) - in this case I don't pass a Request obj, but previously prepare all data needed - but I must do it then in many action methods in almost all controllers (retrieving/processing data from Request is just a simple call for another service, but then it's not centralized)
I'm putting this question, because I have e.g. the following problem to solve:
I'm using the same filters for all different data (from different data-sources) on the whole page.
Filters can be enabled and disabled - and they should be remembered for all the pages for the single session
I decided that saving "disabled" filters to a session is probably the best approach (because by default all data should be seen, i.e. all filters should be in "enable" state)
The 3rd point - saving data (filters) to a session - is what makes trouble in SF2, as described above. For displaying filtered data on page, I need access to a session, and thus access to the Request obj. And this means I have difficulties in keeping "S" in SOLID, because of making dependency on a service's method to always pass a Request obj to it.
Is there any other, better solution than the 2 mentioned (i.e. one, breaking SOLID, or two, code duplication)?
The session is also a service in the symfony di container, you can simply inject session into your servives
Backbone tutorials I have read implement some type of a mini-framework (i.e. Slim) with a RESTful architecture performing CRUD on a server db, like this. The Backbone docs state you need a RESTful api, which I believe is due to the Backbone Route and Sync functionality that keeps models up to date, which is a huge aspect of my choosing to use Backbone.
For example, the line below maps a faux url (route) to the 'addWine' function (within a Slim api):
$app->post('/wines', 'addWine');
Assumption 1: If I have a (PHP) CMS backend (and not a mini-framework) I assume I could simply replace the 2nd parameter (addWine) with my own CMS class method call and return a json object.
Assumption 2 But I would not be able to directly call that same class method from a link in the html without causing backbone to lose state and thus it's ability to sync the model data (and remember the browsers history).
Assumption 3 In that case, I will need to use the Slim api and route backbone urls through (Slim) RESTful CRUD calls in order to access my CMS database to keep backbone happy.
If those assumptions are correct, then it would seem backbone is intercepting those HTTP calls - which leaves me wondering how the whole RESTful + Backbone relationship works. Can you explain some of it?
If my assumptions are incorrect, then I need more help than I thought. Can you help with that?
Thanks
I can't speak intimately to your three assumptions, but as for your final question -- Backbone does not "intercept" HTTP calls -- it constructs them, just as any other javascript library would to create an AJAX request.
Backbone is relatively agnostic to your server side language/framework. Here is what Backbone expects any time "sync" is called:
Backbone's sync function uses different HTTP request types based on which method was called. These different HTTP request types are:
POST
GET
PUT
DELETE
Your framework needs to support all of the above to support the "out of the box" functionality of Backbone. This means that you must specify all of the above routes within your application in order to work with Backbone.
One other thing to note is the "create" and "update" method does not carry post data with the request specifically -- instead it sends a content body with a json digest of the data and expects the server side to properly parse a JSON object and deal with it appropriately.
I say yes to all three assumptions and also agree with #Andy Baird.
Also, the only problem to your project is how to notify Backbone that you have updated the database and you would like it to update itself in the front-end. I can only see two solutions:
1) using Javascript's setInterval() - if you do not need the front end to be updated immediately on DB update, you can check for changes every 1 minute, Backbone knows to only update what has changed and add new stuff but of course this is not healthy to the server if you have 1k active people making repeated request every minute
2) using SocketIO or similar service - this way you can send from the server to Backbone either the entire list of modifications to your DB or a simple 'Please refresh, new stuff waiting'. Check this discussion.
I'm new to Zend Frameworks and MVC type programming (not PHP though) and I'm trying to provide API access to data on my server using the Zend Framework.
I'm using Chris Danielson's article (http://www.chrisdanielson.com/2009/09/02/creating-a-php-rest-api-using-the-zend-framework/) as a base.
I want to provide access to data in the following formats:
(a) http://www.example.com/api/createevent
Data will be POSTed here, success will return an id, otherwise an
error message/code
(b) http://www.example.com/api/geteventdetails/1234
GET request will return data
(c) http://www.example.com/api/getregistrationdetails/1234
GET request will return data
(d) http://www.example.com/api/getregistrationdetails/1234/567
GET request will return data
Questions:
There is a default file which is located at \api\application\controllers\VersionController.php which enables handling of URLs of type: http://www.example.com/api/version . Should I be creating a separate file located at: \api\application\controllers\GeteventdetailsController.php which handles requests of type (b) (and one for every type of request)? If not, where should I be placing my code to handle these multiple request types?
How can I get the parameters passed in (b) to (d)?
To do requests (b) to (d), I need to fetch information from my server's database. Where should I place the code that does the actual MySQL query?
I have used routes a lot in ZF, but not the Rest implementation, having swatted up on the docs and on the tutorial you linked to - I will do my best to help you...
It might be worth looking at the docs for the Rest router (about 1/3 down the page) - it explains that it will automatically create routes for you based on the method of the request; so your naming format of createevent, geteventdetails, etc shouldn't be needed.
Question 1.
Rather than creating the file
\api\application\controllers\GeteventdetailsController.php
I'd create the file
\api\application\controllers\EventsController.php
This will be one controller to handle all the event actions, be that getting, posting, putting, etc. Your suggestion is too specific for the controller as the get, put, etc will be handled at the action level.
Question 2.
The routes described in the docs show you that the final parameter (:id) will be assigned to a parameter in the controller called id.
So accessing the URL /events/ using GET will invoke the indexAction() in your EventsController.php file
And accessing the URL /events/99/ using GET will invoke the getAction() in your EventsController.php file. You can access this id from the controller like this
$id = $this->getRequest()->getParam("id");
OR
$id = $this->getRequest()->id;
You should then write code to query the database for a listing of events or for a specific id. Which brings us nicely on to...
Question 3.
Rather than putting the code for querying the database for events into the controller you should create models for your database tables and rows. I'd recommend using the existing setup in ZF for Zend_Db_Row and Zend_Tb_Table to do this. This will ensure your application/website is MVC.
Putting the code inside the contrller may hinder development later, for example when you write a registation form for an event at a later date in another controller. The logic for creating the event will be duplicated, once in the new controller and once in the Rest controller. You'd be better off centralising this logic into a model for manipulating and querying events.
I hope that helps!
The agavi framework uses the PUT request for create and POST for updating information. Usually in REST this is used the other way around (often referring to POST adding information while PUT replacing the whole data record).
If I understand it correctly, the important issue is that PUT must be idempotent, while POST does not have this requirement. Therefore, I wounder how creating a new record can be idempotent (i.e. multiple request do not lead to multiple creations of a record) in particular when usually the ORM uses an id as a primary key and the id of a new record would not be known to the client (since it is autocreated in the database), hence cannot be part of the request. How does agavi maintain the requirement of idempotence in light of this for the PUT request.
Thanks.
PUT can be used both for creation and for updating complete records. POST is usually used for partial updates and related operations as well as for creating a new type of record on the server without specifying a URL for the resource (e.g. POST to /articles/23/comments returns a 201 status and a Location: /articles/23/comments/283136 header). So in your case (with a sequence/autoincrement ID), you would use that approach.
However, HTML (and thus web forms) is different. It only knows GET and POST, not DELETE and PUT. For deletion and updating operations, it overloads the POST method.
That's why Agavi, by default, maps POST to "write" and GET to "read" - it's the most common use case, and "read" and "write" were chosen because they are relatively neutral and also in a way represent the safety aspects of GET vs POST (safety as in "GET can be called without side effects" and blah).
You can change the mapping of verbs for the AgaviWebRequest implementation in factories.xml; refer to the Agavi users mailing list or the IRC channel if you need help with that (or ask away here). A lot of people on the IRC channel are also quite experienced with URL scheme design in case you need more help with making your API pretty.
Instead of thinking of PUT as creating, think of it as "putting". You put a resource at a URI (ie send an entire resource to a URI).
PUT http://example.com/articles/1
If you repeat this (send the same entire resource to the same URI) you get the same result and you haven't changed the resource at that URI, that's what makes it idempotent.
If agavi's implementation of PUT is idempotent then it is implementing PUT correctly. Otherwise it's not.
PUT can be used to create a resource, except that if the resource already exists (or has already been created by a previous PUT) it will just update it. POST should not update resources, however, if this is simple CRUD. Note that the HTTP verbs do not have a defined mapping to certain actions necessarily, since they're useful for a lot more than just CRUD.
Also note that this question has nothing to do with REST - just proper HTTP usage. So please remove the REST tag.
I've had this problem before. This can be solved by changing the factories.xml