I'm creating a Django/JQuery/MySQL application where I pass a composite data structure 'grid' as
return render_to_response('products.html', grid)
I render 'grid' into a set of UI elements ('td', 'button', 'div' etc. encapsulated in a HTML 'table'.
A typical use case:
User clicks on a certain UI element in the table
jQUery.click() is called which creates a inner 'input' tag for the clicked element.
User can add/modify/delete text from the element.
When focus is lost, jQuery.blur() is called which reverts the original properties of the clicked element such as removing input tag etc.
jQuery.blur() also calls a AJAX function where I do a .post call to send in user modified data back to a URL (function in view).
The called function in view then commits the new changes in database and returns a 'success' event back to web page:
tc_model_instance.update(tc_id=json_data['id'])
Through this use case, as you can see the changes are immediately committed to the database as soon as user eneters data and gives up focus on a particular element. Without using DB transactions in INNODB, how do I go about creating a View-Template association such that any changes in HTML template are asynchronously reflected in the model, but not necessarily written into the database.
A related question:
If possible I'd also like to create a event based bi-directional association between rendered template and my data structures as part of the view in such a way that any changes made either in web browser's UI element or associated view's data are always in sync. I plan to use AJAX for the most purpose. Not sure if forms would make sense in this regard.
Thanks.
You could probably throw a copy of the object into the session map and all posts alter that object instead of the DB directly. Then when the user presses a save button you'd fire off another POST command to the server that would then just call session['my_object'].save().
Note though that the session object is also saved in the DB, so if you are trying to avoid hitting the DB totally what I wrote above wouldn't help.
Related
Question is: How to show data in data-view in such a way that if entity is updated some how dataview is updated too.
This is my Entity named latestReading.
Here is my page LatestReading that show latest readings. It contains three data views.
This page is not called directly, as it expect a object latestReading. Hence a micro-flow named showLatestReadingPage is executed that fetches or create latestReading object and pass it to the LatestReading page and display LatestReading page.
Here is that micro-flow.
getOrCreateLatestReading is a micro-flow that returns us the a latestReading object if it is available or create a new latestReading object if it is not already created and then returns it.
Here is that micro-flow.
These are the properties of first of the three data-views in LatestReading page as shown diagram of LatestReading Page above. Name of this DataView is TemperatureDataView
These are the properties of text widget that is inside TemperatureDataView data-view. Its name is temperatureText. It shows value of temperature in the TemperatureDataView.
And this is the caption of temperatureText text widget:
Problem is when another micro-flow updates the value of latestReading the text widget is not updated. I need to reload it by clicking on navigation link of LatestReading page again.
I need my text widget in data view to keep updating value of latestReading when it is updated my some other micro-flow
The issue is that ‘refresh in client’ only works if the microflow is executed in the same context as the page (client) that the user is seeing. For example if there is a button on the page that triggers a microflow that refreshes the client then it will update the widget. However, if the microflow is triggered by the system (e.g. a scheduled event) then these changes are in a different context. Also if another user triggers a refresh it will only refresh that user’s client. Also if one user is logged in through multiple browsers (i.e. has multiple sessions, it also means that for each session there is a different user context.
The simplest solution in this case would likely be to use an appstore widget that periodically triggers a refresh on the object displayed in the dataview, such as this one: https://appstore.home.mendix.com/link/app/27/ . Simply create nanoflow or microflow with a change action that changes no attributes but refreshes the object.
In Angular, speed is the name of the game and rendering views with useful data as quickly as possible is always sought after. Angular allows us to reference data between the Controller and the View seamlessly using Angular's templating engine, which can make rendering views with correctly bound data lightning fast.
For example, lets say we have a simple Angular App which is simply a table of contacts with fields like First Name, Last Name, Phone, Email, and Address. We then want a Details view that appears when you click on a table row. We can wire up the <tr> to change views on click like this
<tr ng-repeat="contact in Contacts" ng-click="showDetails(contact)">
Then we can change the view and "instantly" show contact data in the new view. For example, we can change an <h1> at the top of the page to be Contact - John Smith using the data that was provided in showDetails.
While this data is being shown, more data can be retrieved from the server asynchronously that will then fill in the rest of the fields.
However, what do we do if we want to get to this details page directly from the url? If the contact table was sitting at /contacts and the details page was something like /contacts/detail/1 then attempting to go directly to /contacts/detail/1 would result in the <h1> above to be blank.
This is clearly because we did not use the showDetails() method to invoke the view and pass the clicked contact into it directly. In this case, we would need to take the contact id in the URL and run an AJAX request to get ALL of the data.
My question is, at what point do we draw the line between trying to make our views and data quickly accessible and making them robust?
Robust is a must.
So we need to start there. Then we can move forward to optimize and make data "quickly accessible", as you put it, as much as possible.
In order to do that, every view in an SPA that is directly correlated to a URL needs to be initially stateless. That basically means that a reload on any url will load the desired view correctly and completely.
We can get the best of both worlds by using nested routes. If every route loads only what it needs, but also draws on parent routes (loading them if necessary, or just using them if they have already been provided) then you can achieve both robustness and "quick accessibility" to data.
In your particular example, the base route would be contacts. Then there could be a nested route inside of that which would display the details of a particular contact, contacts/detail/{id}. Loading the base url would load the list of contacts, and loading the details view would load both the list of contacts and the details of a particular contact. To provide quickly accessible data when going to the nested view, we could include logic that checks to see if the parent view data is already loaded, and only load if necessary. Then when navigating from the contacts to the contacts/detail/{id} view, we could quickly display data from the parent view in the child view, while loading data specific to the child view. A reload at contacts/detail/{id} would simply load both. When navigating back to the parent, the parent data would already be loaded.
If you were to use something like ui-router to create complex routes, then you would not use showDetails() to alter the model, you would use showDetails() to alter the route. Then your model would set itself up based on the route, and your view would follow.
For example, you could have something like:
$scope.showDetails = function(contact) {
$state.go('contacts.detail', { contactId: contact.id });
};
Then the controller could use $stateParams to retrieve any data you wanted for the specific contact from the server (asynchronously using promises). You could also include your own flavour of caching/loading via services to manage things like performance if you found it necessary.
I am pulling some data from a databse and displying it in a list like in this example. I want to implement a search on the top of the page to search the value of the data reurned on the page. This example creates a new view for the search page. Is it possible to implement a search on the current view without creating a new view for the search results.
I don't mind doing it with a new view, but I am just wondering
The view doesn't need to care about what you are doing in the background with the data. It simply displays whatever you are sending to it in a formatted pretty way. Because of this there is certainly nothing wrong with supplying a parameter in a search box and then pushing this to the controller when clicking a search button. The controller will then be doing the requests to your model or repo to filter the data culminating in a return of your view loaded with the data it has found, exactly as it would on your initial load (just now with less data than it did before). There should be no need to create a totally different view for this, the view is just your template for returned data.
I have an element which is rendered via ajax on my "posts/add" view. The element counts the user's clicks with jQuery and saves it in a variable (let's call it $clickCount).
Now, I would like to pass $clickCount back to the /add view, so I can then save it to the database together with severall other form inputs.
I passed $clickCount to the controller (via Ajax) and tried saving in the session, but it seems like the /add view doesn't see it at all. It's as if the element has a completely different session (which to me makes no sense?). So even though I get the variable passed back to my controller, I can't access it from the posts/add view.
I have spent way too much time on this, I really hope someone can help.
Sounds like it might be because you are making an ajax call to save the session variable, but then you have to remember that you haven't refreshed the page, so the session on the page has not changed, and therefore your new session value isn't available to the view yet.
If you don't want to refresh the page after saving the session value, then you need to return the value back as the response from the ajax request, and add it into your page using JavaScript. You could write it into a hidden form field or something if that is appropriate for you to save it later into the database.
Or, if possible, save the value to the database when you make the ajax request in the first place, and eliminate the whole session thing (if this won't impact the database).
in my application I have a NSTableView bound to an ArrayController (arrangedObjects). I also have a Details-View (just some textfields) bound to the same Controller (selection).
Now every time I edit a textfield the changes are automatically send to the ArrayController and the Table changes as well. How can I avoid this? What I want is a "Submit-Button". Changes on the data should only be send to the controller when I press the button and not automatically every time I do an edit.
There are really two answers to this question. The first is more philosophical: in most cases you want updates to the model to occur instantaneously. For the most part users shouldn't have to be bothered with saving, committing, etc. changes the make. Binding's pervasive integration with the NSUndoManager means that anything the user does can be undone (or should be undoable). All user actions should be "low risk" such that making a change and then undoing does not cause unnecessary "harm" to the user's data or the application state. If you're using Core Data for your model layer, you can always roll-back or save a set of changes programmatically using the NSManagedObjectContext's methods. Unless there's a really good reason why the user needs a "Submit" button, don't put one in. In line with this philosophy is Gmail's "Undo Send" functionality. Even sending an email should be undoable (within reason).
The second answer is more practical. Of course there are situations where you're dealing with a backend system that isn't as forgiving of undos as Cocoa. In that case, the best option is to create a temporary model object that serves as the model for the UI (think a View-Model in the Model-View-View-Model (MVVM) architectore). When the user submits the changes, you can copy the temporary model object into the persistent model. In Core Data, you can use an in-memory persistent store backing a separate managed object context to hold these temporary instances and then merge changes from this temporary context into your main context on submit.
This might be enough:
Select the text fields in Interface Builder.
Switch to the "Text Field Attributes" pane of the Inspector panel (hit Cmd-1).
Change the Action popup box to "Sent On Enter Only".