I have a regular restful model that I do get, create, delete and update. On top of that, I'd like to call special actions on that model, like change_password.
The regular RESTful routes are traditional Rails 3 routes:
fetch => GET /api/models/:id
save => PUT /api/models/:id
create => POST /api/models
destroy => DELETE /api/models/:id
But, on top of those, I have special operations:
changePassword => GET /api/models/:id/change_password
activate => GET /api/models/:id/activate
And so on.
What do I need to setup on the model, so it recognizes those new actions, and how to wrap the calls into model methods?
It's fairly simple to add new methods to a Model - just specify the new methods in .extend(). You have to code some of this yourself, but you can take advantage of existing machinery like Backbone.sync (mostly just a wrapper around $.ajax()) and the Model's existing url property:
var MyModel = Backbone.Model.extend({
activate: function(opts) {
var model = this,
url = model.url() + '/activate',
// note that these are just $.ajax() options
options = {
url: url,
type: 'POST' // see my note below
};
// add any additional options, e.g. a "success" callback or data
_.extend(options, opts);
return (this.sync || Backbone.sync).call(this, null, this, options);
},
// etc
});
Just as a comment, from a REST perspective, your changePassword and activate operations should not be GET methods - all GET methods should be idempotent. This is not just RESTifarianism, it's a Good Idea - you could end up caching these URLs (so nothing happens) or hitting them multiple times by accident (usually requiring user confirmation with a POST request). Make these POST calls if you can.
I would advise that if possible add a Password model/controller where you can call save on to change the password. This follows the REST standards and is built in functionality of Backbone.js
If that's not an option, the following is a CoffeeScript example, add this to your model:
activate: ->
unless user.get('active')
(#sync || Backbone.sync).call #, 'activate', #,
url: "#{#url()}/users/#{message.get('id')}/activate"
data: {}
complete: =>
user.set(active: true)
#set(active: true)
Related
I'm new to unit / integration testing and I want to do an integration test of my controller which looks simplified like this:
// ItemsController.php
public function edit() {
// some edited item
$itemEntity
// some keywords
$keywordEntities = [keyword1, keyword2, ...]
// save item entity
if (!$this->Items->save($itemEntity)) {
// do some error handling
}
// add/replace item's keywords
if (!$this->Items->Keywords->replaceLinks($itemEntity, $keywordEntities)) {
// do some error handling
}
}
I have the models Items and Keywords where Items belongsToMany Keywords. I want to test the error handling parts of the controller. So I have to mock the save() and replaceLinks() methods that they will return false.
My integration test looks like this:
// ItemsControllerTest.php
public function testEdit() {
// mock save method
$model = $this->getMockForModel('Items', ['save']);
$model->expects($this->any())->method('save')->will($this->returnValue(false));
// call the edit method of the controller and do some assertions...
}
This is working fine for the save() method. But it is not working for the replaceLinks() method. Obviously because it is not part of the model.
I've also tried something like this:
$method = $this->getMockBuilder(BelongsToMany::class)
->setConstructorArgs([
'Keywords', [
'foreignKey' => 'item_id',
'targetForeignKey' => 'keyword_id',
'joinTable' => 'items_keywords'
]
])
->setMethods(['replaceLinks'])
->getMock();
$method->expects($this->any())->method('replaceLinks')->will($this->returnValue(false));
But this is also not working. Any hints for mocking the replaceLinks() method?
When doing controller tests, I usually try to mock as less as possible, personally if I want to test error handling in controllers, I try to trigger actual errors, for example by providing data that fails application/validation rules. If that is a viable option, then you might want to give it a try.
That being said, mocking the association's method should work the way as shown in your example, but you'd also need to replace the actual association object with your mock, because unlike models, associations do not have a global registry in which the mocks could be placed (that's what getMockForModel() will do for you) so that your application code would use them without further intervention.
Something like this should do it:
$KeywordsAssociationMock = $this
->getMockBuilder(BelongsToMany::class) /* ... */;
$associations = $this
->getTableLocator()
->get('Items')
->associations();
$associations->add('Keywords', $KeywordsAssociationMock);
This would modify the Items table object in the table registry, and replace (the association collection's add() acts more like a setter, ie it overwrites) its actual Keywords association with the mocked one. If you'd use that together with mocking Items, then you must ensure that the Items mock is created in beforehand, as otherwise the table retrieved in the above example would not be the mocked one!
I have added a number of annotations to do simple required field validation in a modal form. Now I need to do a somewhat convoluted check for uniqueness on a couple of the fields involved.
I want to avoid using a custom annotation to do this as the fields that require validation within the model require extra information that does not exist in the model.
I want to be able to add a new rule to the existing validation via script.
Unfortunately I can't seem to get both the new rule and the existing ones to work at the same time.
If I do the following, then only the new rule gets applied, all the existing rules (required fields etc.) disappear.
jQuery.validator.addMethod("uniqueresourceid",
function(value, element, options) {
return ResourceIDValidation(options.resourceSet, value, options.originalresourceidpropertyname);
}, "This resource ID is already inuse.");
var validator = $('#InstitutionModalForm').validate();
$('#Institution_NameResourceID').rules("add", {
uniqueresourceid: {
resourceSet: "Institutions",
resourceId: $('#NameResourceID').val(),
oldResourceId: "OriginalNameResourceID"
}
});
function ResourceIDValidation(ResourceSet, ResourceID, OldResourceIDField) {
var valid = false;
$.ajax({
type: "POST",
url: "#Url.Action("ValidateResourceID", "Admin")",
traditional: true,
contentType: 'application/json; charset=utf-8',
async: false,
data: JSON.stringify({
ResourceSet: ResourceSet,
ResourceID: ResourceID,
OldResourceID: $('#' + OldResourceIDField).val(),
}),
success: function (result) {
valid = result;
},
error: function (result) {
console.log(data);
valid = false;
}
});
return valid;
}
If I remove the 'var validator =...' line, then only the original validation (required fields etc.) fires.
I can't see any reason why this shouldn't be possible, but I can't seem to figure out how to make it work.
I'm not really clear on how the unobtrusive stuff does it's magic, but shouldn't there be a way to hook into whatever validator is being generated by the server side annotations so that I can add a new rule in the JS?
Strictly speaking, this is possible but I can see some very important reasons why you wouldn't want to do this.
Most importantly, this creates a client side validation only. This means if someone nefariously submits the form, or if they don't have JS enabled, that your server side code will not do this validation and probably break.
In addition to that, it makes your code harder to maintain as the validation is not handily visible in your code as it would be with an annotation.
While it is probably a very bad idea to do this, this is how you could make it happen. Adding this code above the "addMethod" caused it to validate as I initially intended.
$('#NameResourceID').attr("data-val", "true");
$('#NameResourceID').attr("data-val-uniqueresourceid", "Resource ID must be unique.");
$('#NameResourceID').attr("data-val-uniqueresourceid-resourceset","institutions");
$('#NameResourceID').attr("data-val-uniqueresourceid-originalresourceidpropertyname","OriginalNameResourceID");
Do this instead: Implement a custom validation annotation as Stephen Muecke suggested in the question comments. It was more work, but in the end is far better practice. This was the most helpful (to me) tutorial I could find on the subject.
A parameter governs what data is to be displayed. The parameter is retrieved from activationData in the activate method of the view model and used in a call to a Web Api method. Data is returned, and added to the view model like this
define(['durandal/app', 'knockout', 'moment'],
function (app, config, ko, moment) {
var vm = {
app: app
};
vm.activate = function (activationData) {
vm.ChecklistInstanceId = activationData.ChecklistInstanceId;
$.ajax({
url: "api/ChecklistInstance/" + vm.ChecklistInstanceId,
headers: { Authorization: "Session " + app.SessionToken() }
}).done(function (data) {
$.extend(vm, ko.mapping.fromJS(data));
});
};
return vm;
});
Inspecting the viewmodel immediately after it is extended reveals that it is decorated with observables exactly as expected. For example, vm.Caption() exists and returns the string I expect, and vm.Section() is an appropriately populated observable array, and so on down a fairly elaborate object graph.
The problem is the binding phase has already occurred, and at that time the view model lacks all the observables to which I'm trying to bind.
Two possible strategies suggest themselves:
obtain the parameter earlier
re-bind
I don't know how to do either of those things. Can anyone tell me how to re-organise my code to allow binding to parametrically fetched data?
A third possibility occurred to me:
define(['durandal/app', 'knockout', 'moment'],
function (app, config, ko, moment) {
var vm = {
app: app,
Caption: ko.observable(),
Section: ko.observableArray()
};
vm.activate = function (activationData) {
vm.ChecklistInstanceId = activationData.ChecklistInstanceId;
$.ajax({
url: "api/ChecklistInstance/" + vm.ChecklistInstanceId,
headers: { Authorization: "Session " + app.SessionToken() }
}).done(function (data) {
var foo = ko.mapping.fromJS(data);
vm.Caption(foo.Caption());
vm.Section(foo.Section());
});
};
return vm;
});
This works because all the observables exist in the binding phase. This might seem surprising given that I describe only the root of a potentially deep object graph, but the fact that the observable array is empty causes the binding phase to exit without a hitch.
Later in the activate handler, values are added to the observable array after ko.mapping has its way with the data, and binding succeeds.
I have a sense of dèja vu from this: it is eerily reminiscent of problems solved using forward declarations in TurboPascal back in the eighties. La plus ça change...
In order to work on a fully-constructed view, you will need to move your logic to either the attached handler or the compositionComplete handler. As you said, at the activate stage, the DOM isn't yet fully constructed. You can read about these lifecycle callbacks here.
Typically, what we do is pass the activationData in through the activate handler, store the activationData locally (if your viewModel is instance-based, then on a property in the constructor), and then reference that activationData in the attached or the compositionComplete handler.
You can fetch the data in the activate handler, and then store the data locally. But that's all you should do there. Reserve view-related logic for later in the cycle. In this case, you may need to return a promise from activate, and then resolve upon receiving your data. You can read about it here.
UPDATE
Take a look at this post, and the conversation there.
Laravel 4: In the context of consume-your-own-api, my XyzController uses my custom InternalAPiDispatcher class to create a Request object, push it onto a stack (per this consideration), then dispatch the Route:
class InternalApiDispatcher {
// ...
public function dispatch($resource, $method)
{
$this->request = \Request::create($this->apiBaseUrl . '/' . $resource, $method);
$this->addRequestToStack($this->request);
return \Route::dispatch($this->request);
}
To start with, I'm working on a basic GET for a collection, and would like the Response content to be in the format of an Eloquent model, or whatever is ready to be passed to a View (perhaps a repository thingy later on when I get more advanced). It seems inefficient to have the framework create a json response and then I decode it back into something else to display it in a view. What is a simple/efficient/elegant way to direct the Request to return the Response in the format I desire wherever I am in my code?
Also, I've looked at this post a lot, and although I'm handling query string stuff in the BaseContorller (thanks to this answer to my previous question) it all seems to be getting far too convoluted and I feel I'm getting lost in the trees.
EDIT: could the following be relevant (from laravel.com/docs/templates)?
"By specifying the layout property on the controller, the view specified will be created for you and will be the assumed response that should be returned from actions."
Feel free to mark this as OT if you like, but I'm going to suggest that you might want to reconsider your problem in a different light.
If you are "consuming your own API", which is delivered over HTTP, then you should stick to that method of consumption.
For all that it might seem weird, the upside is that you could actually replace that part of your application with some other server altogether. You could run different parts of your app on different boxes, you could rewrite the HTTP part completely, etc, etc. All the benefits of "web scale".
The route you're going down is coupling the publisher and the subscriber. Now, since they are both you, or more accurately your single app, this is not necessarily a bad thing. But if you want the benefits of being able to access your own "stuff" without resorting to HTTP (or at least "HTTP-like") requests, then I wouldn't bother with faking it. You'd be better off defining a different internal non-web Service API, and calling that.
This Service could be the basis of your "web api", and in fact the whole HTTP part could probably be a fairly thin controller layer on top of the core service.
It's not a million miles away from where you are now, but instead of taking something that is meant to output HTTP requests and mangling it, make something that can output objects, and wrap that for HTTP.
Here is how I solved the problem so that there is no json encoding or decoding on an internal request to my API. This solution also demonstrates use of route model binding on the API layer, and use of a repository by the API layer as well. This is all working nicely for me.
Routes:
Route::get('user/{id}/thing', array(
'uses' => 'path\to\Namespace\UserController#thing',
'as' => 'user.thing'));
//...
Route::group(['prefix' => 'api/v1'], function()
{
Route::model('thing', 'Namespace\Thing');
Route::model('user', 'Namespace\User');
Route::get('user/{user}/thing', [
'uses' => 'path\to\api\Namespace\UserController#thing',
'as' => 'api.user.thing']);
//...
Controllers:
UI: UserController#thing
public function thing()
{
$data = $this->dispatcher->dispatch('GET', “api/v1/user/1/thing”)
->getOriginalContent(); // dispatcher also sets config flag...
// use $data in a view;
}
API: UserController#thing
public function thing($user)
{
$rspns = $this->repo->thing($user);
if ($this->isInternalCall()) { // refs config flag
return $rspns;
}
return Response::json([
'error' => false,
'thing' => $rspns->toArray()
], 200);
Repo:
public function thing($user)
{
return $user->thing;
}
Here is how I achieved it in Laravel 5.1. It requires some fundamental changes to the controllers to work.
Instead of outputting response with return response()->make($data), do return $data.
This allows the controller methods to be called from other controllers with App::make('apicontroller')->methodname(). The return will be object/array and not a JSON.
To do processing for the external API, your existing routing stays the same. You probably need a middleware to do some massaging to the response. Here is a basic example that camel cases key names for the JSON.
<?php
namespace App\Http\Middleware;
use Closure;
class ResponseFormer
{
public function handle($request, Closure $next)
{
$response = $next($request);
if($response->headers->get('content-type') == 'application/json')
{
if (is_array($response->original)) {
$response->setContent(camelCaseKeys($response->original));
}
else if (is_object($response->original)) {
//laravel orm returns objects, it is a huge time saver to handle the case here
$response->setContent(camelCaseKeys($response->original->toArray()));
}
}
return $response;
}
}
I am trying to add a file to a model using qqfile (though that really isn't relevant here).
I look at the params being passed to the server for update, and I have
{ id: 63, photo: 'foto_file.jpg'}
My understanding was that if an object was passed with an id parameter, rails would understand that as an already existing object, and update that model. If no id parameter is present, Rails would use create.
Is that not correct?? How in this instance can I tell rails to update rather than create?
I'm assuming more code isn't needed here, as my controllers won't really help with the solution because I think the decision is made by rails before it really hits the controller. But I'm happy to post the controller code if it is needed.
--------------- my javascript used to update or create the model ---------------------
render: function(){
var start_form=HandlebarsTemplates['user/userForm'](user.attributes);
$(this.el).html(start_form);
var uploader = new qq.FileUploader({
element: document.getElementById('file-upload'),
action: '/users',
onSubmit: function(id, fileName){
if(MyApp.user.id){
uploader.setParams({
id: MyApp.user.id
});
}
},
debug: true
});
},
The update method is only used when you sent a PUT request, not a POST request. Make sure you're using the PUT method. (If you show your form's code, I can give a more specific answer).
Update -- With your code, try adding this as a parameter to your qq.FileUploader call:
params: {
_method: "put"
}
Rails will look for a _method parameter to handle PUT/DELETE requests.
I couldn't get Dylan's javascript method to work, so in my controller I redirected to my update if the response had an id.
def create
if params[:id]
return self.update
end
#then all my regular create stuff here
end
def update
#all the usual update stuff
end