Say I have a website which shows the user ten images and asks them to categorise each image by clicking on buttons. A button for "funny", a button for "scary", a button for "pretty" and so on. These buttons aren't exclusive. A picture can be both funny and scary.
The user clicks the "funny" button. An AJAX request is sent off to the database to mark that image as funny. The "funny" button lights up, by assigning a class in the DOM to mark it as "on".
But the user made a mistake. They meant to hit the next button over. They should click "funny" again to turn it off, right?
At this point I'm not sure whats the most efficient way to proceed.
The database knows that the "funny" flag is set, but it's inefficient to query the database every time a button is clicked to say, is this flag set or not, then go on with a second database call to toggle it.
Should I infer the state of the database flag from the DOM, i.e. if that button has the class "on" then the flag must be set, and branch at that point?
Or would it be better to have a data structure in Javascript in the page which duplicates the state of each image in the database, so that every time I set the database flag to true, I also set the value in the Javascript data to true and so on?
I would keep the state of the element in the js on the page and just issue state-change requests via Ajax. On the server side it is reasonable to either process directly or introduce a state validation check.
This depends on various aspects of your system architecture, however. If the rating is shared between users or other similar scenarios you may need to enforce the round-trip to check what the current status is (or if you have additive nominal flags)...
The page state should be plenty. After all, the page state is what the user sees and manipulates; and they expect the result of their manipulations to reflect what they see.
Related
This is my question. I have a login for a user. Many users can log in with same credentials. When user/s log in, they see a set of radio buttons. Lets say User A, User B and User C log in at the same time. When User A selects some of the radio buttons, User B and User C should also see them selected in their pages. (and vice-versa) If User B changes a selected radio button again, User A and User C should get that updated value in their pages. Like this most recent selections should be visible in all pages. Please help me solve this.
I've done a similar setup awhile back, when user switches department view, all open pages of the application prompt him about the change and switch to the active department view.
I did it as follows.
Stored desired variables in user session. In your case, since you need this available across multiple users, session won't do - store it in a database or flat file. These variables are updated on radio onChange event in your case.
Make the following JS available to relevant pages. Note, I used onFocus since that was I needed, you may need to use setInterval()
window.onfocus = function(e) {
var_check();
};
function var_check(){
$.ajax({
url: 'home/check_vars_ajax',
type:'POST',
dataType: 'text',
data : {[YOUR DATA]}
}).done(function(data){
// ...
// handle selecting releavant radio buttons here
});
}
To summarize:
Write your radio selection to DB or flat file (via AJAX)
Setup a heartbeat call to check current status on the server (AJAX)
Update radio selection accordingly
Well another way to do it would be to go for WebRTC which basically allows you to screen share the users page and show the results on the other users or vice versa. It has very neat API and there are lot of samples that you can check out. Tutorials are available and their homepage itself is a good starting point
But with regard to your particular problem, I cannot give you a clear answers as the question itself is little broad(in my opinion). So check it out and hope it helps.
You can do it with a simple database query. How it works is, when someone logs into a page, it grabs a variable from a database row. At a set time, the page queries the database. if the value has changed in the database, update that row by one. the other pages will query at your set interval, and update the page with AJAX. It is a nifty way to update all pages at once. Here is a tutorial in this.
AJAX auto refresh
You can see a modified example on my request box on this page
AutoRoxx Radio
It is easily modified. Basics are there.
Taking JavaScript this semester. I cannot grasp how this property can be useful at all. This property gives a Boolean value of true IF the checked attribute was used in tag for the check box object...BUT if I am the one writing the program ...I should know if I wrote that into the program correct? I just do not see the logic in this property. Anybody have a better reason for the use of it?
First, to answer your question, "Don't I know?". Of course not. If you are thinking of a form that is only used to add records, I could see your point but forms are also used to update records and we have no idea what the initial value is for any given record that may need to be updated.
The next thing to understand is that the same concept applies to more than check boxes. For example the text input elements have a "defaultValue" property that parallels the logic of default checked property.
The next point, is these properties would be better understood by novices had they been named "initialxyz" rather than "defaultxyz". Novices think that they are used to identify what should be sent to the server if not populated by the user but that is not what they are at all. They are the initial value, as sent by the server to the client, before the user starts interacting with the screen.
To answer your larger question, these propertied are extremely useful in two cases. The first has already been mentioned which is the "reset" button or as I jokingly call it the "oops" button or "start over". That can occur at the record level that resets every element on the form but it can be used on a field by field basis where only the field that has focus is reset. For example, the escape key is often used for this purpose. The second use for this is to know if the form is "clean" (unchanged) or dirty (changed, in at least one small way somewhere). This is used in too commentary places that you did not think about. The first is to avoid submitting a form with no changes to the server. Why waste resources. The complementary is to pop up the "are you sure you want to lose your changes" when someone attempts to navigate away from a form with changes. You walk the form and compare the current valued to the initial value for each element. If no elements changed the form is clean and allow the user to leave without a prompt. If at least one element is different than it's initial value and take appropriate action which might be to prompt to confirm leaving or it might be to submit the form changes to the server before leaving or something that neither of us have thought of yet.
Hypothetically, you might have a form with lots of fields written in html, and you may want to have a "reset" button which resets all of the form fields back to their initial values. (I don't really know why that used to be a common form button, I've never seen a use for it...) The code to reset checkboxes would then be:
input.checked = input.defaultChecked;
which would be the same for all checkboxes, and then you wouldn't need to track the difference between default checked and no default checked ones separately.
Really though, it doesn't appear to have much use, and I've never used it before.
One scenario would be when you are creating checkboxes dynamically, on-the-fly, in your code. The creation may be dependent on a couple of parameters, some of them depending in turn on selections by the user, from the current screen/page.
You may wish to set what is the state of these newly created checkboxes by default, before the user performs any actions on them.
Exemplifying: Say you have a textbox where the user has to tell you how many new checkboxes you should create for whatever further actions. Then after the user enters the input, your javascript creates N checkboxes, accordingly. And their initial state is set according to "defaultChecked".
Just yesterday I found myself using this same attribute. It comes in very handy when trying to set certain values to default.
Have you ever signed up for something ad then found yourself receiving TONS of unwanted newsletters? or you install one thing and two more things start installing? This happens because there was an option somewhere with a checkbox that had the checked attribute to make that decision for you.
Mostly it is used to make decisions for the user. Comes in handy sooner than later!
BTW: Welcome to the sweet world of JavaScript!
Note: the example beneath is just a fictional and simplified example!
Say that I have two buttons in a Meteor.JS app: one to agree, which adds +1 to a score of a certain element, and one to disagree, which substracts one of a certain element.
If I use class-based events for this (so one to agree, one to disagree), is it possible for a user to manually change the class and overrule conditions set in the template?
<button class="agreement tiny">
Agree!
</button>
If the user clicks on this button, he gets the possibility to remove his agreement:
<button class="remove-agreement tiny">
Remove agreement!
</button>
My question is whether it is possible for a user to manually change the class of the remove-agreement button from remove-agreementto agreement, so that he can add multiple +1s. Is this possible? I've tried it myself and it doesn't seem to work, but I'm (obviously) no expert at this.
EDIT: it does work now. Does this mean I need to implement server-side security for this?
Yes, the user can remove the class. I do this every time a website asks to give a Facebook Like. It's 10 seconds to remove the display:none. 10 seconds for privacy is ok for me.
Every time a clients asks to insert/update/remove something, you need to validate this.
This is have obvious scenario: you need to store the user vote and every time the user tries to vote/down vote you check if the users has already voted. If for reason the user is trying to vote down or up more than 1 time you can log this, analysing and decide if you should ban the user.
You can use the allow/deny rules to check this or even a simple server method. Don't forget to check/block the database CRUD operations that come from the client otherwise... you're screwed!
I have a few divs on a form that are hidden by default (style="display:none;"). When the user clicks a certain radio button, an onclick event executes and exposes the divs. The user is then taken to a review page upon form submit that shows him any errors. If there are any, he clicks the BACK button on his browser to go back to the form and correct them. Caching is enabled so that all of his form contents are there. The problem is, since the form is looking for an onclick event, all of the previously exposed divs are hidden again. Is there any way to make sure they stay exposed when the user clicks back to the form from the review page? I thought a document.ready function would do it, but no joy.
As Yair mentioned, you can use cookies. It cannot be done with pure JS. However, you can also use PHP.
Before the user is transferred to the second page, have JS scan the divs in question, and find which ones are visible. (I'm assuming they all have individual IDs). Store these IDs in a comma-delimited string, or array, and send it as a _POST or _GET to the new page.
Have PHP store it as a hidden value somewhere. You could use a hidden input, or a data-x on something ... as long as it's there.
Have JS on that page that watches for the back click, stops it, and then redirects the user to the previous page, and sends the string or array back to it. Have PHP on that page print it as a JS value, and have JS on pageload show all divs with matching IDs.
Cookies or localStorage if you aim for only modern browsers:
localStorage
Is there any way to make sure they stay exposed when the user clicks
back to the form from the review page? I thought a document.ready
function would do it, but no joy.
You can use cookies in order to manage state in a web-browser. Cookies will help you save the desired user's state.
All javascript code is reinitialized on browser reload. You cannot identify whether the user comes back through the browser.
You can use cookies or local storage to save a value when initial display happens and show/hide the div later on document.ready.
I have used a jQuery script in order to have a countdown script on a php page that I am doing, but I would also like to have a score system in it based on the time the user takes to answer some questions.
I am using some drag and drops and click in a certain link into an image map -which is the only correct link in the webpage- and in the three pages I am using this countdown, but I would like to, once the user has completed the drags&drops or clicked the links, get the number on the countdown just when the user clicked on a "submit" button...but I am not even sure if I can do this.
Alternatively, could I use any countdown script that would let me get the actual number that is being showed just when the user click on the submit button?
Thanks a lot everybody in advance!
Only use the javascript countdown for display purposes, you cannot trust the client.
Keep the count down server side. Store it in the SESSION variable, or in the database.
Javascript is insecure because the client can change it. I could save your page on my machine, open it up, and modify how the timer reports and you'd get a completely different time than you should get. I could also just change the variable using the browsers address bar. The client can always, always change anything in javascript, and you must, absolutely must rely on the server to keep your users honest.
Why not just stash the time (as a numeric value) when you want the timer to start, and then just check the difference when you want to know how long it's been? In other words, you've already got the client computer's clock counting, because that's what clocks do. Just remember what time it was when the drag&drop completes (or whatever point in time serves as your reference), and then check the time again in an event handler for the submit button.