I'm using Spring and would like to find out if there is some technique that can be used to stay on the same page. So, to be more clear, after you click on a link and the handler executes, there is some condition which dictates that the browser should remain on (or be redirected/forwarded to) the page the browser was currently on. Beehive, which is built on top of Struts, has a way to do this and I'm wondering if Spring has something similar.
It really depends on the use case. Are you submitting a form or something similar that could be submitted through XHR instead? If you can't use XHR, a simple solution is to have the controller return a view to the current page, possibly with some additional state information.
Related
I am currently learning JSF and was rather amazed and puzzled when I realized that whenever we use <h:form>, the standard behavior of JSF is to always show me the URL of the previous page in the browser, as opposed to the URL of the current page.
I understand that this has to do with the way JSF always posts a form to the same page and then just renders whatever page the controller gives it back to the browser which doesn't know the page location has changed.
It seems like JSF has been around for long enough that there must be a clean, solid way to deal with this. If so, would you mind sharing?
I have found various workarounds, but sadly nothing that seems like a real solid solution.
Simply accept that the URL is misleading.
Append "?faces-redirect=true" to the return value of every bean's action and then
figure out how to replace #RequestScoped with something else (Flash Scopes, CDI conversation, #SessionScoped, ...).
accept to have two HTTP round trips for every user action.
Use some method (e.g. 3rd party library or custom code) to hide the page name in the URL, always using the same generic URL for every page.
If "?faces-redirect=true" is as good as it gets, is there a way do configure an entire application to treat all requests this way?
Indeed, JSF as being a form based application targeted MVC framework submits the POST form to the very same URL as where the page with the <h:form> is been requested form. You can confirm it by looking at the <form action> URL of the generated HTML output. This is in web development terms characterized as postback. A navigation on a postback does by default not cause a new request to the new URL, but instead loads the target page as content of the response. This is indeed confusing when you merely want page-to-page navigation.
Generally, the right approach as to navigation/redirection depends on the business requirements and the idempotence (read: "bookmarkability") of the request (note: for concrete code examples, see the "See also" links below).
If the request is idempotent, just use a GET form/link instead of POST form (i.e. use <a>, <form>, <h:link> or <h:button> instead of <h:form> and <h:commandXxx>).
For example, page-to-page navigation, Google-like search form, etc.
If the request is non-idempotent, just show results conditionally in the same view (i.e. return null or void from action method and make use of e.g. <h:message(s)> and/or rendered).
For example, in-page data entry/edit, multi-step wizard, modal dialog, confirmation form, etc.
If the request is non-idempotent, but the target page is idempotent, just send a redirect after POST (i.e. return outcome with ?faces-redirect=true from action method, or manually invoke ExternalContext#redirect(), or put <redirect/> in legacy XML navigation case).
For example, showing list of all data after successful editing, redirect after login, etc.
Note that pure page-to-page navigation is usually idempotent and this is where many JSF starters fail by abusing command links/buttons for that and then complain afterwards that URLs don't change. Also note that navigation cases are very rarely used in real world applications which are developed with respect to SEO/UX and this is where many JSF tutorials fail by letting the readers believe otherwise.
Also note that using POST is absolutely not "more secure" than GET because the request parameters aren't immediately visible in URL. They are still visible in HTTP request body and still manipulatable. So there's absolutely no reason to prefer POST for idempotent requests for the sake of "security". The real security is in using HTTPS instead of HTTP and checking in business service methods if currently logged-in user is allowed to query entity X, or to manipulate entity X, etc. A decent security framework offers annotations for this.
See also:
What is the difference between redirect and navigation/forward and when to use what?
JSF implicit vs. explicit navigation
What URL to use to link / navigate to other JSF pages
Bookmarkability via View Parameters feature
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
When should I use h:outputLink instead of h:commandLink?
Creating master-detail pages for entities, how to link them and which bean scope to choose
Retaining GET request query string parameters on JSF form submit
Pass an object between #ViewScoped beans without using GET params
I am trying to show/hide Tabs depending on a user access level that I pass to my View that contains a Telerik tabStrip as shown below:
#{ Html.Telerik().TabStrip()
.Name("Main_Tabstrip")
.Items(tabstrip =>
{
tabstrip.Add()
.Visible((int)ViewData["UserLevel"] < 2)
.Text("Topic A")
.LoadContentFrom("_TopicATab", "TopicA");
tabstrip.Add()
.Visible((int)ViewData["UserLevel"] < 2)
.Text("Topic B")
.LoadContentFrom("_TopicBTab", "TopicB");
tabstrip.Add()
.Visible((int)ViewData["UserLevel"] < 2)
.Text("Topic C")
.LoadContentFrom("_TopicCTab", "TopicC");
})
However, when I call the Action that generates the View after a change in user status, although the View appears to update (I can step through it and see the UserLevel change) the Tab visibility remains as it was on the first rendering of the view.
If I subsequently refresh the Page either in the browser or via a JavaScript location.reload() call then the Tab Visibility works fine.
Additional information:
The Action referred to above calls View() to Render the full page that contains the above View.
Although I was able to work around the problem on this occasion by doing a page reload in JavaScript, I would really like to know why this was necessary and would appreciate any suggestions or solutions.
(I am posting this as an answer, since it is too long for a comment.)
Sorry, I should have been more specific. I meant from where in the page are you calling the action?
Your action returns some html (generated from the view) that is returned to the browser and one of two things happen depending on how the action was called:
(1) The whole page is replaced (and the browser might change the displayed address depending on the request verb)
(2) A part of the page, for example the content of a div, is replaced.
To accomplish (1) you will probably use a call to Html.ActionLink or an old fashioned anchor tag.
I would however advise you to use (2) instead, since it can give better UX, but it is harder to do. You would make an Ajax call, either via jQuery's ajax method, or an Ajax.ActionLink call.
So basically my counter-question was about which of these you are using. My suspicion is that you are requesting the action, but not writing the response anywhere. Can you perhaps show code for the action and the rest of the view, or reduce it to a minimal example to paste here?
More to the point of your question though, I have looked around a little and you are right that showing/hiding the tabs with javascript is not supported out-of-the-box. I did however find these two posts which might still help you
http://www.aspnetwiki.com/page:extending-the-telerik-mvc-client-api
http://www.aspnetwiki.com/telerik-mvc:dynamically-add-a-tab-to-the-tabstrip
I'm retro-fitting a .aspx page with AJAX functionality (using VB, not C#). The codebehind populates the page with data pulled from a web-service. The page has two panels that are populted (with different data, of course) in this way. On a full page refresh, one or both panels might need to be populated. But populating Panel 2 can take a long time, and I need to be able to update panel 1 without refreshing Panel 2. Hence the need for AJAX (right?)
The solution I've come up with still has the old .aspx page with .aspx.vb codebehind, but introduces a Generic Handler (.ashx) page into the mix. Those first two components do the work on the user's first visit or on a full page refresh, but when AJAX is invoked, the request is handled by the .ashx page.
First question: Is this sound architecture? I haven't found a situation online quite like mine. Originally, I wanted to make the .aspx page into the AJAX handler by having the codebehind implement IHttpRequest, and then providing "ProcessRequest" and "IsReusable" methods, but I found I couldn't separate a regular visit to the page from an AJAX request, so my AJAX handlers took over even on the first visit to the page. Second question: Am I right to think that this approach (making the .aspx page do double-duty as the AJAX handler) will never work? Is it impossible to tell whether we're getting a full-page request or a partial-page (AJAX) request?
If the architecture is good, then I need to dynamically generate a lot of HTML in the .ashx file, right? If that is right, should I send HTML back to the client, or should I encode it in some way? I've heard of JSON encryption, but haven't figured out how to use it yet. So, Third question: Is "context.Response.Write" the only pipeline for sending data back to the client? And, if so, should I send back HTML or some kind of JSON-encoded objects?
Thanks in advance.
It sounds as if the page requires some AJAX functionality added to the UI.
Suggest using an UpdatePanel for each web form element that needs to have AJAXy refresh
functionality. That'll save you from having to refactor a bunch of code, and introduce a whole lot of HTML creation on your .ashx.
It'll be more maintainable over the long run, and require a shorter development cycle.
As pointed out by others, UpdatePanel would be a easier way - but you need to use multiple update panels with UpdateMode property set as conditional. Then you can trigger the update-panel refresh using any button on the page (see AsyncPostBackTrigger) or even using java-script (see this & this). On the server side, you may decide what has triggered the partial post-back and act accordingly by bypassing certain code if not needed.
You can also go with your approach - trick here is to capture the page output using HttpServerUtility.Execute in your ashx and write it back into the response (see this article where this trick has been used to capture user control output). Only limitation with this approach is that you can only simulate GET requests to your page and so you may have to change your page to accept parameters via query string. Personally, I will suggest that you create a user control that accept parameters via method/properties and will generate necessary output and then use the control on your page and in ashx (by dynmaically loading it in a temperory page - see this article).
EDIT: I am using jquery to illustrate how to do it from grid-row-view.
$(document).ready(function() {
$("tr.ajax-grid-row").click(function() {
$("#hidden-field-id").val($(this).find(".row-id").val()); // fill hidden filed
$("#hidden-button-id").click(); // simulate button click
});
});
You can place above script in the head element in markup - it is assuming that you have decorated each grid-row-view with css class "ajax-grid-row" and each row will have hidden field decorated with css class "row-id" to store row identifier or the value that you want to pass to server for that row. You can also use cell (but then you need to use innerHTML to get the value per row). "hidden-field-id" and "hidden-button-id" are client ids for hidden field and submit button - you should use Control.ClientID to get actual control ids if those are server controls.
JSON is not for that purpose, it is to pass objects serialized with a nice light weight notation, is you need to stream dinamically generated html using ashx, response.Write is what you have. You may want to take a look at MVC
Or you could use jquery if it's just html, the simpliest would be the load function, or you can look into Ajax with jquery. Since the ashx can be served as any resource it can be used in the load function.
I agree with #p.campbell and #R0MANARMY here. UpdatePanel could be the easiest approach here.
But then like me, if you don't want to go the UpdatePanel route, I don't see anything wrong with your approach. However, generating the html dynamically (entirely) at the back end is not a route I'll personally prefer (for the maintainence reasons). I'd rather prefer implementing a solution that will keep the design separate from the data.
I have a webservice that I need called, the result of which determines whether or not the user is allowed to submit the form.
Since this call is from javascript and not from code behind is it not reliable? Is there any way the user can get around the check -- by either going in with firebug and enabling the submit button, somehow making the method give a different result than was actually returned by the webservice, any other ways of being able to get around it?
Basically is there any way to call a webservice from javascript and have it's result determine whether or not a form can be submitted, and actually prevent the user from submitting the form at all? -- whether or not they have firebug, etc...
No, not possible.
Just to name a few possible reasons:
what if javascript is disabled?
what if the user submits the raw POST (using libcurl, for example)?
what if the browser, that the user is using interprets javascript in a way, different from your expectations (think, portable devices)?
Javascript validation is there for your users' convenience only and should never ever be used as a means of providing security.
You can never prevent the user from making an HTTP request that mimics submission of the form. While disabling the form via Javascript prevents submission for 95% of the users who both have Javascript enabled and don't want to circumvent your access control, anyone who understands HTTP can make the call and you are correct in showing that anyone with Firebug can do it in a matter of seconds.
Javascript isn't reliable for preventing anything. It shouldn't be seen as a security-wall, as it's too easily disassembled with things like firebug, iedevelopertoolbar, and many other browser toys.
Even if you could prevent them from submitting your form on your page, nothing stops them from creating a brand new form, on their own page, and point it toward the action of your form. Thus they're removing themselves from your "secure" environment, and instead chosing to play in their own.
Your suspicion is correct; the user can easily get around any possible Javascript validation.
You will need to use server-side code.
No, it is not reliable. Try disabling Javascript in your browser to see for yourself how easily you can get around it.
The user could simply disable javascript in their browser, or use something like NoScript. The best you could do is to try setting the form action itself in the return from the Ajax request, that way the form, as loaded, won't submit (except to itself). This will probably stop casual users but would be no impediment to a slightly more determined (or just bored and tech savvy) user. You will need to check on the server side whatever you do.
In general, no. You can make the form hard to submit without going through Javascript. Make the submit button not an actual submit button (<input type="submit">), but a pushbutton (<input type="button">) that submits the form in its onClick handler.
As everyone else said, no you can't do it. The only real solution is to have the web service return some dynamic value which the Javascript inserts in a hidden form input. Then whatever server-side code processes the form submission should reject the request if that value is not present.
Clarification:
Put simply, I'd like to put an ASP.NET UpdatePanel inside the info window of Google Maps. This would mean that users could interact with my application from within an info window, without refreshing the page and without closing the currently open info window.
Does anyone know if this is possible?
Update:
Thank you to all those who have so far responded. Very much appreciated.
What I have gleaned from the answers is that:
the update panel has it's own "mysterious mechanics" which might be causing the UpdatePanel to not work correctly inside the InfoWindow. Going down the more direct route of using JQuery to make ajax calls to simple web services should eliminate the hidden complexity of the UpdatePanel and enable the functionality I want.
I am still intrigued as to why the UpdatePanel approach does not work, and as to why using one would "break the model" of Google Maps, when surely an UpdatePanel merely renders as HTML and javascript with a link to the XMLHttpRequest object.
Is it possible to place ASP.NET code inside Google Maps info window?
I'd like to place an UpdatePanel with some AJAXified asp:Button's inside the info window.
AFAICT you simply provide the HTML to place in the info window as a string, so was thinking of rendering a UserControl to a string and placing that string in the info window for the browser to render. Does anyone know if this is likely to work?
If this is not possible in Google maps, does anyone have any idea whether such an implementation would be possible with the corresponding Virtual Earth technology?
José Basilio is right. Instead, use $jquery Live Events and put regular HTML in the Info Window then use Ajax calls with jQuery to get the interactivity you want. Reframe the problem.
VirtualEarth has tigether integration with SilverLight, which should mean that you'll have greater .NET control over your web mapping application. With most Google Maps implementations that we've done we typically just use pure HTML/JavaScript/CSS solutions to create AJAX functionality. Thus we would inject HTML/javascript into the InfoWindow class, for any custom functionality that we needed.
Consider another approach and possibly. What you are really looking for is to be able to respond to a server side event. Maybe something like this if you really and truely need to respond to server side events.
http://windyroad.org/2006/07/25/event-driven-ajax-part-1-pushing-server-side-events/
Once you are handling the events on the client in javascript you can do whatever you like to the map
I'm not sure I'd take this approach, but if you want to get ASP.NET code within an info window, you could use an iframe.
Alternatively have you considered an ASP.NET control such as GoogleMap Control, which would handle all the integration for you?
Rich
UpdatePanel != AJAX. Take a look at using jQuery to make Ajax calls ($.ajax) and creating simple web services/etc. to achieve what you're after. While technically you could wiggle an UpdatePanel into there somehow, it just isn't worth it.
Look here for an excellent example on calling AJAX/web methods with jQuery.
Have you looked at the ExtInfoWindow control? Since you did not state your problem, I can't say whether it is a solution, but it seems that it should be mentioned here.