HTTP POST and graceful degradation - ajax

I have a web application which among other things contains a table of items created using an Ajax callback. A bunch of form fields at the top of the table allow me to filter the items that will be displayed in the table according to various criteria and show it.
Some parts of the table have lists of items with an [X] marked next to them that I can delete by clicking on those items.
Now, if I were doing this the non-ajax/javascript way, the page would receive a bunch of POSTed data fields and then would render the table accordingly. I can do this but I would also like to Ajaxify the entire setup. My questions are regarding this.
How would I create the [X] button. A simple <a> would "work" but it's a GET modifying state so I don't want to do that. The way I'm doing it now is a tiny form with a hidden parameter than holds the item to be deleted and a styled submit button that's the [x]. If I ajaxify this, I can get the response and do the needful.
How do I keep my backend DRY? I don't want to have two completely different bits of code for the Ajaxified version and the regular ones. What I'm doing right now is having the non-ajax version submit to a URL that changes the state and then redirects to the main page again (similar to a PRG type system). With the Ajax enabled, I simply call the URL and ignore the redirect but use the returned data to adjust the table. Is this the "right way"?
Any other advice on graceful degradation on how to keep my backend DRY?

I would put each row into it's own form (with method='POST'), and include a hidden field to say which item is to be deleted. The [X] would submit the form, and in the form's submit event, if no XmlHttpRequest is present simply submit the form to the server which would delete the item and redirect to the same page again (this is good practise to avoid a reload from resubmitting the delete POST).
If an XmlHttpRequest is present, set it up to POST with the id of the thing to delete and then remove the row if the request succeeded. You could set a flag in the AJAX request so that redirect doesn't happen, just a success (200 OK).

Related

Apex - set items values after submit

I have to regions with items on my page. One of them is to edit data, another one is display only. Editable region is hidden on page load and shows when users click on a button. I'd like to pass data between these regions after submit a page. Are computations after submit the only way to do that? I tried with processes after submit, before header etc. but it didn't work.
I'd like to have one pl/sql code to pass data between two regions after submit, how to do such a thing?
Other options include
dynamic action (you'd use Set value)
button's Redirect to page in this application (where you'd redirect to the same page; Link Builder then lets you choose which items will be set to which values)
If you still can't make it work, consider creating sample page on apex.oracle.com; then provide login credentials so that someone might have a look.

How can I change my URL before loading my view?

I have a CodeIgniter webpage containing (i) a list of items and (ii) a form to add a new item or edit the details of a selected item.
To select an item for editing, I have an "edit" anchor tag with a hyperlink ending with ?id=nnn. This results in a GET request that populates the detail fields of my selected item and redisplays the list. My URL now contains site_address/index.php/country?id=151.
When I submit my changes the list is updated correctly but my URL remains unchanged. What do I need to do in my controller to remove "?id=151 after my update was successful?
Thanks for your help.
I'm not sure of everything you are doing, so I'll just answer directly:
in your controller, after you update, you can:
redirect('site_address/index.php/country');
Does that fit what you mean?
Through php there's no way to change URL after request expect redirecting
redirect('controller/method');
and you can success message using session flash message after redirecting, if that what makes you want to reload the view

APEX: Call JavaScript function after validation but before processing

I have been tasked with re-creating an old PL/SQL Web Toolkit front end in Application Express (Apex).
I would like to display a popup after the page is submitted and after computations and validations.
The page can be submitted by clicking a button OR by hitting enter.
I have googled and got a modal popup working (called by javascript) but I can't seem to call it at the right point. I can call it on submit (before the validations etc.) but not after the validations.
I have tried creating a branch to URL at the correct processing point and then have the URL set to:
javascript:openForm();
But then I get a page will not display error.
Can anyone out there explain how I could do this?
Apex Version: 4.0.2
Oracle 10g
I suppose what you want to do is to perform the validations, have values submitted to session state, but not execute further processes.
However, when you submit the page it is sent to the server; and everything you see in the page processing region will sequentially fire. There is no way to halfway through the processes call a javascript function, since basically you are not on the clientside anymore.
What you can do is to create a branch after your validations to the same page. Redirect to it but provide a REQUEST value, for example OPENFORM.
Create a dynamic action, firing on page load, with a true action that executes javascript and opens up your modal page. Then set the condition on your dynamic action to Request = Expression 1, providing the request value to Expression 1 (OPENFORM).
(Note that this is the Conditions region, and not the 'Condition' field of the 'When' region)
This should cause the page to be submitted, validated, then re-loaded but with a request value, and the dynamic action firing, opening your modal page.
Just a point of interest:
If you have actual processes on this page though, then be careful with the Enter key. Buttons by default submit to session with the request value set to their name, and thus making it possible to conditionally execute processes or branches. The enter key does not submit with a request value set i believe. So if your branch is conditional, the enter key might simply skip over it.

Maintain SelectList Options over postbacks

I was wondering if there is a way to maintain your list of options on a Select List in MVC 3. I am pretty new to MVC but in WebForms you could populate the DropDownList on the first load of the page and then the ViewState would maintain that list for all of the AutoPostBacks. This was nice because often, DropDownLists are populated by query to the database. I know that ViewState does not exist in MVC but is there a better way of repopulating the SelectList without having to hit the database during the request of every post?
You have several options here.
Your selected value will be posted back. With that in mind since you no longer have ViewState you ideally want to
Have your Repository (if you dont have one - create one. You simply ask the repository for the data and it controls the caching or loading) that you ask for the data in the drop down, cache the data and just simply request it again. Rebind your list (use DropDownFor)
Use MVCContrib's Html.Serialize to essentially ViewState it, however the cache is a bit cleaner and doesnt rely on data sent back and forth.
Also remember that after you post your data, if everything is 'good' you want to REDIRECT back to your "GET" action to reload the data and display to the client. This was an issue in web forms that sometime a user saw XYZ after postback but after a refresh saw YXX. Using the PRG pattern in MVC posts-redirects-gets to load up fresh data.
After your post you should generally only redisplay the data if there was a validation error, otherwise redirect to a get method.
Your controller receives the value on postback. You have to place that value back in the model to tell the view what the selected value is.

Is it possible to persist (without reloading) AJAX page state across BACK button clicks?

I am familiar with several approaches to making the back button work in AJAX applications in various situations, but I have not found a solution that will work gracefully in my specific scenario.
The pages I am working with are the search interface for a site. You enter terms in a normal search box, click "go and wind up at a search results page. On the search results page there are a ton of UI controls for filtering/sorting the search results to find what you are looking for. Some of the operations triggered by these controls may take a (relatively) long time to complete (e.g. several seconds).
This latency is fine in case where the user is initially filtering/sorting their results... there's a nice AJAX spinner and so on... however when the user clicks on a search result and then clicks on the BACK button, I would like the page to instantly be restored to the state it was in when they clicked through.
I can restore the states using IFRAMEs/fragment identifiers as a dictionary of page history, but what ends up happening is that when the user first hits the back button the initial page is loaded, then it (re) makes the AJAX query to get the page state back, which triggers the AJAX spinner and another wait of possible several seconds.
Is there any approach that does not require this kind of two-stage load of the page when the user returns to the page via the BACK button?
Edited to add: I am partial to jquery but I'd be happy with solutions that depend on other libraries/toolkits or that are standalone/raw javascript.
Edited to add: I should've added that I'm trying to avoid cookies/sessions because this prevents people having multiple brower windows/tabs open and manipulating different sets of search results at the same time.
Edit: Matt, can you elaborate on your proposed solution (triggering a page change event via fragment identifer)? I see how this would help with BACK button clicks across the same page but not coming BACK to the search results page after clicking on a specific result.
Just use a cookie.
Have you investigated the YUI Browser History Manager?
Try to use localStorage object. Here is crossbrower libs jStorage and WEBSHIMS json-storage
Would it help to trigger a page change event using the "Add some info to the # at the end of the URL approach".
That way, clicking the back button shouldn't actually change the page, and you should be able to restore state without the first page load.
Use something persistent that is tied to the user's profile.
Cookies and sessions are good ideas, but you can also keep those stuff in the database. That gives you an added advantage of being able to save the user's filtering preferences accross different browsing session.(if, for exampple, he was looking for something in the office and then decided to continue searching when he is back at home).
It all depends on the complexity of the filters and weather or not it is something you think that the user will want to use accross diffrent browsing sessions..
Edited to add: I should've added that
I'm trying to avoid cookies/sessions
because this prevents people having
multiple brower windows/tabs open and
manipulating different sets of search
results at the same time.
You can create a random token and assign it to the fragment identifier.
on first page load create a token if no fragment identifier is set
before navigating out, store all the temporary ajax data in a cookie with that token as index.
when hitting back, if you have a fragment identifier set, load the data from the corresponding token in the cookie.
you can even add a "time" field to expire tokens, etc...
sample cookie (JSON):
{"ajaxcache":[{"token":<token>,"time":<time>,"data":<data>}, ... ]}

Resources