Have been working on a smaller project with php here and got lost. I'll explain in two parts.
Part 1: I have index.php and a getitem.php. Index contains a form with multiple select objects with no options (at start) with the exception of one. After selecting an item from the one with options available I make a query via getitem.php&[parameters_here]. The php then echoes options with values and texts.
This form then guides you to fill every field this way. These options are added on the go with object.innerhtml. Everything fine.
The problem kicks in when you hit the refresh button. Select items lose their options (with the exception of the one). How to keep these settings on refresh? Keeping them in a _SESSION? Checking the session for every single select item seems too brute force.
Part 2: Would fixing this help me out with a library like this; to see the dynamic options with images? I believe these two parts are connected.
Thanks.
About Part 1:
The key point is refreshing the page. First let us consider the case what is happening now - you are probably keeping the options selected using $_POST. After the selection and reloading is done it shows the response of POST action [as your data is being posted into the same page - guessing from your scenario]. Now when somebody reloads the browser the POST request becomes empty. So all the selections are lost.
There can be lots of ways/tricks for this.
$_SESSION can be one of them / $_COOKIE can be one of them / through some JS you can use browser local storage, etc.
The main concept will be the fact to keep the values somewhere where a browser refresh doesn't effect. So though $_SESSION seems brut force to you -- it is a logical option.
About Part 2:
I think these two parts are not connected. As long as you are using regular select options for showing your options - they are not connected -- as your part two deals with styling your option values not how the work.
Related
I'm working on a basic voting system where I have 2 HTML pages (both on the same domain).
On page 1 there are two buttons of which the person should choose one.
One page 2 I want to visualise the chosen option in a graph.
The goal is that if a button is clicked on page 1, the data on page 2 updates automatically without refreshing the whole page.
In order to do this, I tried saving the clicked option in a localStorage. I managed to get the data by writing a variable using localStorage.getItem(''). However, when I get the data, I have to manually refresh page 2 for the result to show. Is there a way to update the data on page 2? So if I press multiple buttons, multiple responses will show on page 2?
I also saw that there is a possibility of using WebSockets. Since I'm only familiar with HTML and JavaScript, I was wondering whether it's possible to solve my issue without setting up a server and run things locally. If that's not possible, what would be the best (and maybe easiest) way to solve my issue?
If you have page 2 successfully reading a variable that you get from local storage (which is being updated by actions taken on page 1), you can make a timer with setInterval to read from local storage every x milliseconds. Then the graph will update on its own.
See documentation for setInterval here.
Maybe the best and simple solution is setting specific url parameters for each button selection.
Then on the page 2 you simply show conditionally according the url parameter.
I'm very new with JavaScript and I'm struggling to implement something which I don't think should be very complicated.
What I want to do is:
form is open in browser with a drop-down list of records in a database
if the desired option is not in the list, the user can click on a link next to it to add a new entry to the database
this will open a new window with an additional form for this entry
on clicking submit the processing script will run to insert this information into the database
when the processing script has completed, the window will close and the drop-down list will refresh so that it includes the new option (but without losing any other information in the form)
Maybe that last thing with the list refreshing is quite complicated (unless the list only in fact loads from the db on click?) but everything else should be simple enough, I think. I've tried all sorts of things but nothing that's got close enough to working to be worth posting here.
Could someone please give me some sort of idea of the sort of functions I should be using and roughly how to implement them? I don't necessarily need precise code, just a framework to work from. (I'll learn more in that case anyway.)
ETA: I should add that I've been trying to work with window.open() and window.close(). I don't even really know if this is the best method?
No, that's not(at least relatively) complicated. What you'll need is jQuery and jQuery UI(these frameworks are just suggestions, you may chose any other if you like) to achieve that. So...
form is open in browser with a drop-down list of records in a database
This part is easy, just a simple html form with a select tag and a add link/button on it. You will need a JavaScript function to refresh the select options from database. For that I suggest this or this -there are many others on the web- post.
if the desired option is not in the list, the user can click on a link
next to it to add a new entry to the database
this will open a new window with an additional form for this entry
The easy way to do this is using jQuery UI Dialog Widget to open the popup with the new form.
on clicking submit the processing script will run to insert this information into the database
On that form you'll have to use jQuery Ajax to send data to database through your server language(PHP, ASP.Net, JSP, whatever...). Some examples here and here.
when the processing script has completed, the window will close and the drop-down list will refresh so that it includes the new option (but without losing any other information in the form)
So when data processing was complete, you call the refresh select function that you created before and close the dialog on the ajax success callback. Example here.
And this is it. Now it's up to you. Hope it helps.
I have a little web app (which only has 1 page) that allows user to input and select some options. The input texts and selections will be displayed in another div in the form of table. You may want to refer to the example here: http://jsfiddle.net/xaKXM/5/
In this fiddle, you can type anything and after you clicked submit it will get the text input and append them to another table #configtableTable
$('#labels #labelTable tr:last').after(addmore);
$('#configtable #configtableTable tr:last').after(displaymore);
I'm using cherrypy as a mini web server (and thus major codes are written in python) and i know that it has session here but i have no idea how to use it at all as the example given is not really what i want to see.
FYI, i'm not using PHP at all and everything is in a single page. i simply show and hide them. But I want the page to remain as showing #configtableTable and hiding #labelTable even after refresh. Note that the fiddle is just part of the web app which will only show all these after getting a reply from another device.
Not sure about cookie because all the links i've found seem broken. How about jQuery session? Is it applicable in my case? I need some examples of application though :(
okay, to conclude my questions:
1. can i save the page state after refresh? and how? which of the methods mention above is worth trying? is there any examples for me to refer? or any other suggestions?
2. can i simply DISABLE refresh or back after reaching a page?
Thanks everyone in advance :)
Don't disable Refresh and / or back navigation. It's a terrible idea - user's have a certain expectation of what actions those buttons will perform and modifying that leads to a bad user experience.
As for saving state, while you could use session or cookies, if you don't need that data server side, you can save the state on client side as well.
For example, you could use localStorage
Alternatively, you could create an object out of the data in the table, JSON.stringify() it and append it to the url like this: example.com#stateData.
In case of either option, at page load, you'd have to check if there is state data. if you find there is, then use it to recreate the table, instead of displaying the form.
The disadvantage of the first, is that not all browsers support localStorage.
The disadvantage of the second is that URLs have a length limit and so this solution won't necessarily work for you if you're expecting large amounts of data.
EDIT
It appears that Midori does support most HTML5 features including localStorage however, it's turned off by default.. (I'm trying to find a better reference). If you can, just point Midori to html5test to see what HTML5 features it supports.
I can't quite figure out a work around for using "Use view dialog for choices" in a web based application.
My Question is how can i convert this settings in my field in the Control Tab then Choices, in choices "Use view dialog for choices" then Use current database and access view and a specific column.
Thanks in advance :)
"Use view dialog for choices" is almost always a way to get around the restrictions on the return value of a formula. For instance, you'd use it when #DbColumn in a choices formula for a listbox or dialog list choices formula would cause an error.
The upshot of that is that there's no "one-shot" workaround for the web. A direct functional replacement would be to open the view in a pop-up window or overlay div, and attach some JavaScript to the view in order to override the default web behaviour and force the return of values to a field on the main document. This approach will work well, but it may require server settings that allow the entire view to be served at once (the maximum lines to display per page will probably be less than you need), and it's subject to breakage if the HTML used to display the view ever changes.
You can use LotusScript or Java in a WebQueryOpen agent to populate a conventional widget (the list of a element) in a Rich Text field, either using PassThru HTML or a "Treat contents as HTML" form. That would involve getting the view, then doing a document-by-document (or category-by-category) run through the view index to get the column values you need. (If you take this approach, use the ColumnValues rather than the document field name to retrieve the values -- the cost of opening the document to read the values is high, and your code will take many times longer to run.)
You can also get the view as need using an AJAX request and a ?ReadViewEntries query, which will return an XML representation of the view. Again, you may have to have the maximum view lines per page limit upped in order to get the amount of data you need. You can get around that, though, by using a "suggest" method that doesn't begin retrieving data until the user enters at least one character into the field.
All of these approaches mean using a separate form for the web. That's easy enough -- you simply create a form with the same alias (or name, if you're not using aliases) as the one you're using for the Notes client. In the list of forms in Designer, you can use the hidewhen tab to hide one from the Notes client and the other from the web. (Note that you can create an additional form for mobile devices the same way if necessary.)
I can't get more specific than this with the information at hand. If this is insufficient to point you in the right direction, then edit your question to be more specific (and post a comment to this reply -- I don't spend a lot of time on SO, but I do spend time on other StackExchange sites, so I'll be notified).
Unfortunately, you have to develop it yourself.
http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=AJAX%20Name%20Picker
AJAX-based name picker is a good start I guess.
I am creating a site that utilizes the jQuery UI tabs. Whenever the user flips between the tabs, the tab they just left is posted back to the server in order to save the state.
One of the tabs in particular is a bit complicated in that, if I select a particular data option, other options need to be disabled. However, because of the POST, those options reenable themselves in the view when I go back to the tab. The current solution I have found to fix this problem is to check to see if the specific option was selected and to disable the other options appropriately (which happens as the user flips back to the tab). However, this seems like too much work. I am wondering if there is any way for the disabled attribute to remain on the various options even through the POST. (If the answer is "No," I'll accept that, but I wanted to see if there was another alternative to ensuring the view is correct for the user.)
Edit: I wanted to add some code demonstrating the post that I am doing when the user switches tabs. (Particularly based on the responses.)
$.post($(form).attr("action"), $(form).serialize(), function (data, success) {
if (success) {
// Inject the resulting form back into the parent of the page.
var parent = $(form).parent();
parent.removeData($(form));
parent.html(data);
processTabAfterLoad(tab_index);
}
});
The processTabAfterLoad function does all of the selections and setting the state of the tab back to what it previously was.
If I were you, I'd take a different approach. It seems like your goal in posting back to the server when navigating is to preserve a user's location in an application so when they return, you can restore this state. Rather than reloading the whole page through a POST, what you could do instead is do an "AJAX" post to tell the server to store the user's UI location but do all of your UI enabling logic client-side. That way, not only will UI transitions look smoother, but you'll reduce server load and make the application more responsive.
It'd only be when the user does the initial GET of the page that you'd need to look up the last-known UI location. If there's something stored for that user, you would add logic to set the UI's initial state when the page loads.
Update:
Indeed you are doing an AJAX post, but you're also apparently inserting the HTML response from that post into your UI. That is a somewhat unusual pattern (excepting ASP.NET update panels). Typically, you'd either POST the data and expect no content in the response or you'd receive data back from the post which you'd apply to the UI rather than receiving a fragment of the UI.
If you're committed to the way you're currently handling form submittal, you could look into the jQuery live function which can apply changes to elements as well as newly-inserted elements that match the criteria.
Tabs are usually navigation techniques. Imho, its a bad practice to postback and redirect when a GET (i.e. an ordinary link) would do. A GET resets viewstate back to a known point, is a small payload, doesn't require a page life cycle that gets discarded anyhow before the redirect, etc.
I could also be completely wrong here-- I'm making some guesses since I can't see any code.