Develop Reference

ASP.NET MVC Controller waiting for Model before returning responses

I need to creat an algorithm in which all calls to a specific action from the users will return the views at once even when the calls were not received at once . I have a static Model with a timer inside when the timer fires his event I want all the ActionResults of that action to be returned at once (From security reasons) . Is there any way I can block the Action Result From retuning until a model method/Event is being called? Should I use AJAX for such a thing ? and if so how would I go about returning a new view to the users with AJAX? (Only some users actually need to update the view I need to process the input they send in the model to know if the view needs to update)

If you want to send messages to client in very specific time I don't think regular HTTP request are a way to go. You should probably be using WebSockets for that... that simply sounds just like a push message.

Vue js and favorite/like button

I'm wondering how favorite, subscribe or like buttons work.
I don't understand something.
For exemple:
A user like a post with id 243.
A ajax request is sent to the server with the id of the post (243) [here comes back end stuff, the user's favorite list is updated, including that post] and the server sends back a success response.
Now, how I suppose to deal with modifying the like button to actually display that is liked (permanently, including refresh).
How can I achieve that in Vue JS. How things get updated? I don't understand this part.

If the server sends back a successful response you can increment the number that is already there.
This initial number is something you have gotten either through a prop, directly from the server or through an initial AJAX request.
If you want to "permanently" update the amount of likes on your button you have to persist it to a database(or some other storage medium). On you server you could have a route that accepts a post id as an argument and increment that specific user post:
/incrementlike/243
That is where you would make a POST ajax request to. Most of the time in an MVC framework you would have a controller action/method mapped to this route that holds the logic to respond to this call.
If you are interested in the part that happens after you make an AJAX request to the server to increment your like on the backend side, I suggest you read up on routing or MVC structure.

How you would do this is really done on a case by case basis. It really depends on a number of things, for example what your backend does to a post when it is liked.
If you would like a general 'explanation' to the process I attach it below, this is not really Vue specific, but the general idea is the same:
Frontend side:
Modify the local state of you post to set the proper flag, ex. post1.liked = true immediately when it is clicked, before sending the request to the server.
Make sure your GUI represent this change. ex. Base the color of the button on the property 'liked' of each post.
If a failure response it received from the server, notify the user and allow them to 'try again' or something similar.
When refreshing the page, make sure changes are fetched from the server, If you have done the backend part correctly, the modification of the state of the post will be correct in the data you receive from your backend (post1.liked will be true)
Backend side
When the request comes in, modify the state of the post the correct way and make sure that next time the post is fetched, the new state is sent.

What's the correct way to handle complex objects with Restangular?

In the app on which I'm working I use a REST API with
Angular 1 on the frontend. I use the extendModel function of Restangular in order to initialize the data that I receive. During the initialization phase I create a lot of cross-references and the object becomes cyclic. Here comes my problem. In order to put or post my data back to the server I have to either copy the object by picking just the fields that I need or I can work on the same object and delete all the references that I created and restore them when I get a response from the server. I feel like these 2 options kinda go head-to-head with the intended usage of Restangular. Is there a better way to do this?

Using AJAX and jQuery to store data

I am looking for a way to use AJAX and jQuery to store data from one form in another without losing the values. I want to be able to keep this data away from the front end user and allow them to remove the information should they wish to. I need to be able to get this information out when the user submits the data. I would like to be able to store the values in an associative PHP array if possible, for example:
<?php
$information = array(
"first_information"=>array(
"name"=>"Sam Swift",
"age"=>21
),
"second_information"=>array(
"name"=>"Example Name",
"age"=>31
)
);
?>
I would have used a database for this but because of volume this will not be possible. I want to keep the data away from the user so that they have no access to it at all, the data should be held where the user has no way to see it, access it or change it. This is due to the nature of the data and all of it should be as secure as possible.

Any information that you store client-side is naturally going to be accessible and mutable by the client. If this sensitive data is data that the user is entering, then you really shouldn't worry about them manipulating the data (because that is what they are supposed to be doing). If however it is data that is being sent by the server - and never displayed or used in that form by the client - this is data that should never leave the server in the first place.
Ajax is not specifically a solution to this problem - whether you send the data asynchronously (i.e., piecemeal with Ajax) or as a full HTTP post is immaterial. You need to store the sensitive data on the server only along with a session ID to associate it with the client session.
Without knowing exactly what data you are storing nor what you are doing with it, it is difficult to advise you how to proceed. You should rethink how you are structuring your application if you are sending sensitive data for the client to work with. The client should only ever see the input and the results. The processing should be done on the server.
For example: perhaps your user is adding an amount to a bank balance. The user enters the amount on the client. but you don't want the client to see or be able to modify the actual value. You could send the balance to the client, perform the addition operation, then send the total back to the server. Far better would be for the client to send the amount to add to the server, which would then add the value to the balance, and return a confirmation for the client to display.

ExtJS 4.1 - Store.add() (followed by sync) vs Model.save()

FIRST: I realize this question has been asked here: in ExtJS, is it better to call Model.save() or Store.Sync()? - however I wish to examine this further, specifically regarding minimizing XHR's and unnecessary overhead on both the client and server. I do not feel either of these points were addressed in the linked question.
I have a somewhat large application designed for enterprise resource management, consisting of many models, views and controllers. I handle all responses from my server by establishing a listener to Ext.Ajax requestComplete and requestException events. I took this approach rather than writing duplicate event handlers on every model's proxy afterRequest event. This enables me to have all of my back-end (using the Zend Framework) controllers responding with three parameters: success, message and data.
After a successful request (i.e., HTTP 200), the method run for requestComplete will inspect the JSON response for the aforementioned parameters. If success is false, it is expected that there will be an error message contained in message, which is then displayed to the user (e.g. 'There was a problem saving that product. Invalid product name'). If success is true, action is taken depending on the type of request, i.e., Create, Read, Update or Destroy. After a successful create, the new record is added to the appropriate data store, after delete the record is destroyed, and so forth.
I chose to take this approach rather than adding records to a store and calling the store's sync method in order to minimize XHR's and otherwise round trips. My current means of saving/updating data is to send the request to the backend and react to the result on the Ext front end. I do this by populating a model with data and calling model.save() for create/update requests, or model.destroy() to remove the data.
I found that when adding/updating/removing records from a store, then calling store.sync(), I would have to react to server's response in a way that felt awkward. Take for example, deleting a record:
First, remove the record from the store via store.remove()
Invoke store.sync() as I have store's autoSync set to false.
This fires the AJAX destroy request from the store's model proxy.
Here's where it gets weird.... if there is an error on the server while dropping the row from the database, the response will return success: false, however the record will have already been removed from the ExtJS Data Store.
At this point, I can either call store.sync(), store.load() (both requiring a round trip) or get the record from the request and add it back to the store followed by a commitChanges() to avoid calling an additional sync/load and thus avoiding an unnecessary round trip.
The same goes for adding records, if the server fails somewhere while adding data to the database, the record is still in the ExtJS store and must be removed manually to avoid a round trip with store.sync() or store.load().
In order to avoid this whole issue, as I previously explained, I instantiate one of my model objects (e.g. a Product model), populate it with data, and call myModel.save(). This, in turn, invokes the proxy's create or update depending on the ID of the model, and fires the appropriate AJAX request. In the event that the back-end fails, the front-end store is still unchanged. On successful requests (read: success: true, not HTTP 200), I manually add the record to the store and invoke store.commitChanges(true), effectively syncing the store with the database without an additional round trip and avoiding unnecessary overhead. For all requests, the server will respond with the new/modified data as well as a success parameter, and conditionally a message to display on the client.
Am I missing something here, or is this approach a good way to minimize XHR's and server/client overhead? I am happy to provide example code should that be requested, however I feel that this is a rather general concept with fundamental code.

I think you have eloquently argued your position. I don't see anything wrong with the position you have taken. My only reproach is to point out that autoSync setting on a store that backs editable grid is a far less verbose way of accomplishing the task, albeit with less control.
To add, the overhead which you point out is typically due to the unexpected or I would call edge cases that may need special handling or an extra refresh of data. You could add listeners for those specific cases and leave the rest functioning with terse defaults.