There is the store with direct proxy. I want to create new record. Direct proxy sends it to server and recieve sended data width NEW ID. I want to insert this ID in the grid, but...
Added record shows for a moment and then It become nulled (all field are null). I see null id and nothing more. How to update that record (or do any action) to see it in the grid correctly with new id?
I don't think you need to anything special to insert record to the grid. The way ExtJs base store/proxy classes work is this - when store send update to the remote server it will try to parse new records from the response. And it should automatically replace existing records in your store object (which to this moment will already have new record, but without Id and with phantom = true).
So you need to make sure that response you're receiving from the server does contain new record and that your proxy is configured properly to parse it from the response.
Related
Let's say I have a quiz written in JavaScript. There are four different possible answers to each question. The participant clicks his way through the quiz one by one, he can cancel it at any time.
Now I want to save the user's click path including the respective timestamps. My idea is to record the click path as a JavaScript object and to transfer this object to the server via AJAX and save it in a JSON file after each click. Does that make sense?
The tricky things seem to me to be (1) to update the correct object (the correct line(s) in the JSON file) within a quiz session (no session cookies) for each click from the second click and (2) to append a new object for a new quiz session, both, if possible, without reading and rewriting the entire JSON file every time.
Your opinions and ideas are appreciated.
Edit: I have control over the backend and I'm using PHP.
Now I want to save the user's click path including the respective timestamps. My idea is to record the click path as a JavaScript object and to transfer this object to the server via AJAX and save it in a JSON file after each click.
Rather than sending the object to the server via Ajax and saving it in a .json file, you can, more simply, store a JSON (including timestamps) in localStorage and update it there.
See the localStorage API:
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
localStorage is both:
more robust / persistent than keeping the data in an object
less elaborate than Ajax-ing data to the server repeatedly
I am caching some data like thumbnails and also JSON in our web app.
Now I want to delete old data when I reach the disk space.
Chrome shows in his web tools (not perfectly, it doesn't show the correct time for self-created responses) the attribute Time Cached in the Cache Storage.
So this data must be somewhere and I want to use it.
My plan would be to do work with cache.matchAll and sort the result by the Time Cached attribute to delete the oldest one.
But match All just returns normal Responses, where I don't have Time Cached.
Actually CacheAPI stores the new response over the old one,if the request URL is the same, so when you cache.match(event.request) you always get the newest (and only one). Also, in my case the response has a 'date' header, which you can compare against the current date and find out if you need to fetch from network or not
The way it works not is that when I call for:
client.record.getRecord('a_new_record');
it will call the server with action 'CR' (see http://deepstream.io/docs/constants.html#Actions for reference) but I only want the client to be able to read and not create a record, even if it doesn't exist.
The reason for this is that I don't want the client to be able to create unlimited records. I want to control this on the server instead.
I can split the action received if it is 'CR', then create the specific record if it doesn't exist and then the client can request the record but I don't really want to hack it this way.
So the question is: Is there a way to send only 'R' when the client tries to fetch a record, or does it have to send 'CR'?
I solved this by using an RPC instead that creates a document in the database and then respond with the newly created ID. That way the client can get the new record directly by its ID.
I'm not sure what is the best practice.
I have some big and complex objects (NOT flat).
In that object I have many related objects - for example Invoice is the main class and one of it's properties is invoiceSupervisor - a big class by it's own called User.
User can also be not flat and have department property - also an object called Department.
For example I want create new Invoice.
First way:
I can present to client several fields to fill in. Some of them will be combos that I will need to fill with available values. For example available invoiceSupervisors. Then all the chosen values I can send to server and on server I can create new Invoice and assign all chosen values to that new Invoice. Then I will need to assign new supervisor I will pull the chosen User by id that user picked up on server from combobox. I might do some verification on the User such as does the user applicable to be invoice supervisor. Then I will assign the User object to invoiceSupervisor. Then after filling all properties I will save the new invoice.
Second way:
In the beginning I can call to server to get a new Invoice. Then on client I can fill all chosen values , for example I can call to server to get new User object and then fill it's id from combobox and assign the User as invoiceSupervisor. After filling the Invoice object on client I can send it to server and then the server will save the new invoice. Before saving server can run some validations as well.
So what is the best approach - to make the object on client and send it to server or to collect all values from client and to make a new object on server using those values ?
Think in terms of complexity of your business processing.
What you need is the client creates a new invoice. To do this, the client provides several different input parameters, calls the process and gets the response. This is your first scenario. Simple and clear.
On the other hand, the second approach involves a communication protocol - give me this, I give you something as a response, then give me something else. This sounds unreasonably complicated. You'd have to carefully inspect what happens when the communication breaks at some point. Should a distributed transaction be involved? If yes, do you really need such complexity?
I would opt then for the first scenario. You don't unnecessarily complicate the contract between the client and the server.
Backbone.js makes a POST request when a new model is created and saved, but it doesn't consider the model to be saved (i.e, further saves result in PUTs not POSTs) until the model has an id.. how should the server return the ID of a newly created model so that backbone.js can set it (i.e, how should it respond to the initial POST)?
If backbone.js doesn't handle that, I assume the best way to do it is using the success handler to set the ID?
You have two options. The first is to return the same JSON structure for a POST request as you would a GET request for the show action (returning a single item.) This uses a single request.
From the documentation:
Set a hash of model attributes, and sync the model to the server. If the server returns an attributes hash that differs, the model's state will be set again.
The other option is to trigger a fetch on your collection after you save. This will take more than 1 request though and will always be less efficient.