I am writing my first Rails app using the twitter gem. I'm simply retrieving search results and trying to cycle through them individually every 5 seconds or so.
My thought was to create a variable and have this variable represent the array index and simply update this variable dynamically with Javascript (every 5 seconds or so). What's the best way to achieve this on the client-side? AJAX? Javascript?
Does this make sense? I will be glad to provide more context if helpful. Thanks.
Sounds you're trying to build a "recent tweets" marquee of some sort. Without knowing your requirements, you could try simply loading the ten most recent tweets in Rails, putting them in ten hidden divs, and then using jQuery just to cycle through the different tweets on the page.
If it is a requirement to "update" the most recent tweets without the user refreshing the page, then yes, you'd probably need an AJAX call.
It's hard to tell what you think you're asking: by the time your JavaScript is executing the server is no longer involved.
If you want to update some sort of count on the server side and persist it in a meaningful way, you can do so via Ajax.
What are you actually trying to do, though?
Ruby runs on the server while JavaScript (usually) runs on the client.
The Ruby generates an HTML document (perhaps with embedded JS) and the server delivers it to the client.
At that stage the Ruby has finished executing. The only way to do anything further with Ruby would be to make a new HTTP request to the server. This could be done by following a link, submitting a form, setting location.href, using XMLHttpRequest or numerous other techniques.
This would cause the Ruby program to be executed again (or a different one to be executed) which would do whatever it did with the input data.
You cannot simply "set a variable" on the server from the client.
In my particular case, I used ruby's .to_json method to convert the data and then manipulated it with javascript. This gave me the flexibility to loop through the data pretty seamlessly. Atleast it seemed to work for my particular situation. Thanks for the help guys!
Related
I have an application where the application's user relates to an HTML page during the application's runtime.
During runtime, the HTML file is being continuously updated. In order to handle every update, the HTML file is being refreshed at a fixed interval.
Is there any other better way to achieve this with more efficiency and/or to hide the refreshing technique from the user's perspective?
Any help will be greatly appreciated.
If what you're doing doesn't involve retrieving data from a server, and instead involves some kind of process that occurs on the page itself, like a clock, I would use setInterval
setInterval(function(){myFunction()},1000);
This would call myFunction() every second, and inside of that function you can change visual elements as appropiate.
You may also want to consider using a Javascript MVC framework such as Backbone.js or Angular.js, which handle changing the appearance of html elements mapped to javascript variables over the lifetime of an application for you.
From your question it sounds as if your updating the HTML file on the server in response to user actions. I'm guessing that's not literally what you meant. If it is, though, there are almost certainly better ways to do what you want to do -- depending on what, exactly, it is.
If you are just showing new information to the user, you will want to use Javascript to update the page's DOM. The easiest way for a beginner to do that would be to start by looking at jQuery tutorials. With Javascript (possibly aided by jQuery) you can easily update the content of any part of your page, without needing to actually change the original HTML file in any way.
If you want the page to be updated for everyone who visits it at a later date, then you need to put the new information in a database, and get the content from the database when you the page is requested or loaded.
It would greatly help if you specified exactly what you were trying to do.
I have an update query to which I am passing a JavaScript array called "newdata", obviously, that didn't work so I don't know how to pass my JavaScript variables to ColdFusion in order to run an update query. How I can see surfing some webs? ColdFusion doesn't have access to Javascript variables. Here's my code, regards!
<cfquery name="updatereserva" datasource="Prueba">
UPDATE reserva_habitac
SET FechaENTRADA = newdata["#firstdate#"]
WHERE idRESERVA = newdata["idreserva"]
</cfquery>
Is there another way to do this?
There are several ways.
You could put the JavaScript variables into a form, and submit that to a specific page in your app.
You could execute an AJAX request that posts your JavaScript array as JSON to the desired page in your application
Etc.
ColdFusion has some built in support for AJAX, but there are also a ton of JS libraries and frameworks that could do just as good (if not way better) of a job. There is, after all, nothing ColdFusion-specific about an AJAX request; CF just ships with some functionality to help, if you want to use that.
The important thing is that in designing your app, you need to remember that JavaScript and ColdFusion operate in different contexts--the former on the client (browser), the latter on the server. While this is certainly not an impediment to making a very robust JavaScript-fronted app (or even an app that just used JavaScript here and there to talk to ColdFusion), you do have to design a bit differently than you would with a non-JS app, so it's important to get the difference clear and go from there.
I'm working on a real-time JavaScript Application that requires all changes to a database are mirrored instantly in JavaScript and vise versa.
Right now, when changes are made in JavaScript, I make an ajax call to my API and make the corresponding changes to the DOM. On the server, the API handles the request and finishes up by sending a push using PubNub to the other current JavaScript users with the change that has been made. I also include a changeID that is sequential to JavaScript can resync the entire data set if it missed a push. Here is an example of that push:
{
"changeID":"2857693",
"type":"update",
"table":"users",
"where":{
"id":"32"
},
"set":{
"first_name":"Johnny",
"last_name":"Applesead"
}
}
When JavaScript gets this change, it updates the local storage and makes the corresponding DOM changes based on which table is being changed. Please keep in mind that my issue is not with updating the DOM, but with syncing the data from the database to JavaScript both quickly and seamlessly.
Going through this, I can't help but think that this is a terribly complicated solution to something that should be reasonably simple. Am I missing a Gotcha? How would you sync multiple JavaScript Clients with a MySQL Database seamlessly?
Just to update the question a few months later - I ended up sticking with this method and it works quite well.
I know this is an old question, but I've spent a lot of time working on this exact same problem although for a completely different context. I am creating a Phonegap App and it has to work offline and sync at a later point.
The big revelation for me is that what I really need is a version control between the browser and the server so that's what I made. stores data in sets and keys within those sets and versions all of those individually. When things go wrong there is a conflict resolution callback that you can use to resolve it.
I just put the project on GitHub, it's URL is https://github.com/forbesmyester/SyncIt
I'm building an AJAX 'web application' where, once the UI is loaded, calls to the server are for 'data exchange' only. As a result a lot of UI manipulation will be done using Javascript. Lets say the Javascript retrieves some data consisting of multiple fields from the server using AJAX. To put it on the screen I can think of multiple approaches -
Call methods like createElement() and appendChild() to build an interface to display the retrieved data
Populate the .innerHTML for the container element then for every data field lookup a container in the newly added HTML and populate it. The data that goes into .innerHTML could be stored in a JS variable or contained in a hidden node, or fetched using a seperate AJAX call.
Have the interface stored in a hidden node. Clone it (using cloneNode()) and put it in the actual container (using appendChild()) and then populate it with fields like in method 2.
and there are probably more ways.
Could you share pros, cons and possible gotachas in these approaches from cross-browser support, performance and coding complexity point of views?
Somewhat related question: Is client-side UI rendering via Javascript a good idea?
Thanks.
ok, let's start off:
Use toolkits
First you would want to invest time learning a JS toolkit. While others suggest native JS is good (which it really is), but you would not want to waste time on building apps that don't work cross-browser or spend too much time testing it. People in the community have invested their time in doing that for you. Show some love to the open community and use their product. I personally use jQuery, but there are others like Dojo and YUI.
But still use native JS whenever possible. It's still faster.
Structure your code
After a toolkit, you need some structure. BackboneJS will take care of that. It's to structure your code so that your code is reusable and well.. won't end up as spaghetti on your screen. Other tools like RequireJS are also useful for those scripts that need other scripts to run.
Templates: From strings to elements
Then, with that, you now have a toolkit but you still need to build the interface. It's better if you use a templating engine like Mustache or Handlebars. These render templates for your UI from strings (yes, plain strings of HTML). Just send over your template data from the server, store it in your app (in a variable or browser localstorage), and reuse it as necessary. No need for cloning hidden nodes!
Don't touch that DOM
As for approaching the DOM, you should touch the DOM only when necessary. DOM is slow, manipulating it is he** slow! that means you should avoid unnecessary animations, avoid excessive element append and remove, as well as changing styles. Check this article about avoiding too much reflow and repaints. Face it, the user won't event notice the round corners of your boxes, or the gradient background and don't even care if you did a slide animation or a fade-out. What they want is to get the job done and not adore the fireworks display.
Also, remove anything that isn't on screen. You might end up having 20% content on screen, and 80% off screen - a waste of memory.
Cache: fetch once, store, use infinitely for later
Now, your app is getting heavy and you want to shave off some HTTP requests. You can do this by caching. I usually use caching mostly on the templates so that every new UI, you don't need to load again from the server. You can do this by storing stuff in an object. you can go a little further and use the browser's localStorage when available.
Caching isn't all for the network. Let's say you have some complex calculations you want to use later, or some text from an unfinished form, use the cache for that too.
Avoid HTTP requests (or at least lighten them up)
While lightening up your app by using AJAX, you will inevitably be tempted to use AJAX just about anywhere - don't abuse it. Often times i see people who aggressively poll the server (every half-second or less). This not only strains the server (too many requests), but also the browser (wasting processing cycles) and the network (bandwidth). There are several practices done these days to avoid added HTTP requests:
Image Spriting - The art of placing a lot of images into one image and using background-position to change the image. Surely beats 100 individual HTTP requests
Use JSON for textual data - AJAX was meant to use XML.. then came along JSON that was a fat-free, platform-independent format of strucured data.
Do not return HTML-formatted data - With exemption of templates, which are HTML strings, you should never return HTML-formatted data over the wire. Have JS do JSON+templates on the client-side instead.
I'm building a similar app (Lightweight CMS)
In my view the approach you take will be dependent on the complexity of data that you are sending from the server > manipulating on the client side > and returning back to the server and db.
The cms that I'm working on is very basic and does not require heavy-duty manupulation on the client side. TinyMCE is as far as it will go.
Initially I was building the client admin area by echoing <input> from php and then collecting the data by parsing the DOM, converting to JSON and AJAX it back to the server (I found this code very helpful)
That of course required the user to hit "save" after editing or adding new data.
I later on decided that I needed something even more responsive and simpler than that so I'm now re-implementing everything for Jeditable which AJAXes the data as soon as the client hits "OK" on that particular field. No "main save" required.
To conclude it's really an area that is pretty uncharted. I mean, it appears to me that people in the industry do not like to blur that line between back-end and front-end and find "one solution" that will do the entire DB>SERVER>CLIENT>SERVER>DB operation.
I'd love to see how you solved your problem.
Just my 2 cents.
I'm working on a plugin for Google Sketchup that is written using the Ruby API. Within this API is a WebDialog class which one can use to render HTML and move data between the WebDialog and the Ruby side of the plugin code. I'm using this class to build a UI for my plugin.
Data is sent from the WebDialog to the Ruby side asynchronously. Due to subpar documentation I was not initially aware of this and now that I'm a ways into my plugin it's began to create some problems for me. Specifically: when multiple successive calls are made from the WebDialog to the Ruby side, only the last call is executed. So, I clearly need to devise some sort of "bridge" which will prevent calls from the WebDialog to the Ruby side from getting lost -- which is, I think, basically an "event loop" or "message pump" system.
My problem is that I haven't a good idea of how to do this. What I'm hoping is that someone can provide me with some sort of resource that lays out a framework for how such a system should work -- what sort of checks are needed, the sequence in which they're performed, etc. I know this can be a terrifically complex task, but I only need something basic: basically, a way of making Javascript stop when I send a request to Ruby, not proceeding until I get the data I need back, and dealing with any potential errors that may crop up.
Any help would be very much appreciated!
I've spent a great deal of time with the WebDialog class. I planned to write such a pump, but I found that I could do it differently with more reliable results.
( My WebDialog findings: http://forums.sketchucation.com/viewtopic.php?f=180&t=23445 )
Alternative Method
SketchUp > JavaScript
My alternative method was that I didn't try to push data from the WebDialog to Ruby. But instead had Ruby pump the WebDialog because Webdialog.execute_script is synchronous.
I send a command to the WebDialog with a query. The Javascript then processes this and put the result into a hidden INPUT element which I then use ´WebDialog.get_element_value` to fetch the content of.
All of this I wrapped up into a wrapper method the will process the return value and convert it into appropriate Ruby objects. http://www.thomthom.net/software/sketchup/tt_lib2/doc/TT/GUI/Window.html#call_script-instance_method
The outline is:
Make a call ( .execute_script ) to clear the hidden INPUT element
Make the actual call which JS will process and put the return value into the hidden INPUT
Use .get_element_value to fetch the hidden INPUT value
All this is synchronous.
Javascript Pump
Javascript > SketchUp
If you really need to pump information from JS, then I think you need to do something like this:
JS: push messages into a message queue
JS: Send a message to SU that there is messages
SU: When the callback notifies about new messages, query JS for the next message and continue until there are no more messages. This should work as it'd be similar method as described earlier.
The concept would be to store up your messages and then hand over control to the SketchUp side which can pump it synchronously.
(Untested theory.)