I know Stackoverflow doesn't want discussions, so I will try to ask an answerable question here: basically, I am building a admin area with naught but a table that has a few columns like project name, due date, sort of normal stuff.
But is there a technique that allows non-polling updating of when attribute(s) changes in the server, it gets reflected on the user's loaded page?
The table's data comes from a JSON call to the server, and it gets rendered with some javascript onto the table. Real simple stuff. If you must ask for an example. sure, just a table of first and last names.
Homer | Simpson
Lisa | Simpson
Bart | Simpson
This page is opened on many of our users, then if I change Homer to Remoh, without having the user refresh the page, I want the updated name be, well, updated on the table display.
Does Websocket or the pub/sub pattern have something to do with this?
Thank you!
You're looking for a websocket or pub/sub system, exactly as you think.
If this is a Rails application and you're using AJAX stuff -- and it sounds like both things are true -- then your best bet is Juggernaut, which makes the entire process seamless and easy.
It's relatively painless to use, and the author has a great sample app called Holla that almost solves your problem by itself.
If I understand your question correctly, you want all changes to the model data to reflect on the admin panel without the need for refreshing the page. That sounds like a job for some simple. AJAX.
In your js.erb file for your admin page, poll for changes every x seconds and if the results of that query are different than whats currently being displayed. Update the table's data.
Of course this is limited to how often you are calling the function with setTimeOut, but the plus side is that you can tweak that to be just what you like.
If you'd like something more 'out of the box' and more instantaneous. I'd go with #Veraticus's suggestions.
Related
I've built a Rails app, basically a CRUD app for memos/notes.
A notes title must be unique. If a user enters a name already taken a warning message is shown prompting them to chose another.
My question is how to make this latency for this feedback as close to zero as possible. When creating a note little UX speed bumps like this will get annoying for user quickly.
Of course the main bottleneck is the network. Inspired by Meteor (and mini-mongo) I was thinking some kind of local storage could be a solution?
I.E. When app first loads, send ALL JSON to the client with ALL note titles. The app (front end is Angular JS) could check LocalStorage (or App Cache, Web SQL?) instead of incurring a network round trip. The feedback would be instant.
I've used LocalStorage in the past to augment an app, but in the scenario it'd really seriously depend on it. I'm not sure how confident I'd be building on something that user might not have. Also as the number of user Notes/Memos I have doubts how feasible it is to send a JSON object down the wire with ALL the note titles. That might get pretty big. On the other hand MeteorJS seems to do this with no probs.
Has anyone done something similar or have any pointers? Thanks!
I don't know how Meteor works here, but you're right that storing all note titles in localStorage is not a good idea. Actually, you don't need localStorage here, you can just put it in a JS array, because you need this data only once (when checking new note title).
I think, there could be 2 possible solutions:
You can change your business requirements and allow non-unique title. Is there really a necessity for titles to be unique?
You can verify note title when user submits form. In this case you can provide suggestions for users, so they not spend time guessing vacant title.
Or, if titles must be unique only within a user (two users can have same title for their notes), you can really load all note titles in JS array and check uniqueness while users types in a title.
Or you can send an AJAX request checking title uniqueness as soon as user finished typing the title. In this case you can win some seconds.
Or you can send an AJAX request as soon as user typed in 3 symbols. The request will return all titles that begin with these 3 symbols, so you don't need to load all the titles.
I am not sure what is better perfomance whise so I ask you guys.
The problem is following:
I have a system where each User gets a certain amount of credit for certain events. So I gave my User an attribute named creditscore that gets altered on those events. Everything works well. But now I want the user to actually see what he did when and how much credit he got for this.
What would be better here:
Saving the whole history in a text attribute and add lines for each event
or
writing an extra model associated with the user and create an instance for every event.
or
or
something way different?
Since there are several events per user per day it would be either a huge text or a huge amount of instances. What would be better looking at website performance.
You absolutely do NOT want to store the history in a text attribute. Management of this will be a nightmare as will querying the data.
You could create a CreditEvent model and store the individual events in there. That would work fine.
However, before you start, check rubygems.org and ruby-toolbox.com to see if someone has already done the hard work. I know of at least one gem that seems to do exactly what you want to do:
https://github.com/merit-gem/merit
I have a new feature in my Rails project. I need to insert a "New!" flag in its menu, so user will notice that a new feature is available. Once the new feature page is visited, this "flag" must disappear.
How is it possible with Ruby on Rails?
The absolute simplest way is to look for a sawFeatureX cookie and set it when the page is rendered or the user dismisses the notification.
A more robust solution would be to store the info on the user model in the db, but that ends up giving you a lot of one-off boolean fields which may or may not be what you want.
There are MANY variations. You could use something like HelloBar to point out the new content without inlining it into the menu. So. Many. UX. Variations.
But for a one-time thing, a cookie or db-backed solution seems simple and easy.
I hate this problem.
A cookie is easy, but gross and doesn't scale. You really don't want to pay the price of sending this data back and forth on every request until the end of time.
Saving on the user record seems like a sin against database design.
A separate DB table with all these "I saw feature X" seems like such overkill and I hate something that is just going to grow without bound being in my main DB.
You can put it in Redis, memcached, but do you really need to store it in RAM? that's the most expensive place to do this.
I think the ideal solution is something like https://www.prefab.cloud/documentation/once_and_only_once which is a service (i wrote) that stores this little "bob saw X" off in a database I don't need to manage/care. It handles cacheing etc so that it's as fast as having it in Redis/etc but durable and doesn't get expired.
Apologies in advance as I'm sure this topic has no doubt been asked before but I couldn't find any post that answers my specific query.
Bearing in mind that I'm new to MVC this is where I have got to. I've got a project developed under VS 2010 using the MVC 3 framework. I've got a search page which consists of 6 fields and a nested model which itself holds around 3 fields.
I can successfully post all this data back to itself and the data is successfully passed as a model and back agian so the fields keep the data which the user has supplied.
Before I move on to actually using this search criteria on another view a thought hit me. I want to keep this search criteria, and possibly even the search results in memory for the duration of the users session.
The reasoning behind this is simply to save my users time by:
a) negating the need to keep re-inputting their search criteria regardless of how they enter or leave the search page
b) speed up the user experience by presenting the search results more quickly
The later isn't as important as the first requirement.
I've done some google searches and indeed had a look through this site on similar topics. From what I've read using sessions (which I would typically use if developing a PHP site) is a no no. From the reasons I've read as to why you shouldn't use sessions seem valid and I'm happy to go along with it.
But now I'm left in a place where I'm scratching my head wondering to myself what exactly is best practice to achieve this simple goal that could be applied to similar situations later down the line in the project.
I also looked at the OutputCache method and that didn't behave as I expected it to. In a test I set the timeout for 30 seconds. After submitting a search I clicked the link to my search page to see if the fields would auto-populate, they didn't. But then clicking the search button the values in the cache were retrieved. I thought I was making progress but when I tried to submit a new value the old value from the cache came back i.e. I couldn't actually change my search criteria with the cache enforced. So I've discounted this as an avenue to explore.
The last option seems to suggest the use of cookies as the most likely candidate, but rightly or wrongly I feel this isn't the best solution. I would have thought the MVC 3 design pattern would have an easier and recommended method of persisting values. I'm sure there is but I've just not discovered it yet.
I have started to use JQuery and again this has been mentioned but I'm not sure this is right direction to take either.
So in summary my question really comes down to what is considered by the wider community as best practice for persisting data in my situation. Effiency, scalability and resiliancy is paramount as I'll have a large global user base that will end up using this web app.
Thanks in advance!
Pete
I'd just use cookies. They're simple to use, you can persist them for as long as you want or have them expire when the users closes their browser, and it doesn't sound like you are storing anything sensitive in them.
Sometimes at websites all comments or other data from DB is hidden by default. When user click at link like "Display comments" all comments from database are dynamically selected and placed under the content. It must be great for mysql performance, because content is generated only when user excatly need it. I would like to implement this stuff at my app.
I've got one idea to do this so far. Remote action with #comments = Content.comments and next page.insert_html at RJS template. Is it good idea or maybe I should choose different way?
The decision is purely based on the application that you are developing. For example if in case of stack overflow it does not make sense to show only the question and show answer link. But in case of a blog post it may be fine.
In the above situation, I don't think there will be a good improvement in performance by removing the comments of the content on show page. We can achieve the same functionality by making use of javascript methods. Hide the content on page load and show in on client request.