I want to make a custom 404 error page.
Where customers, if they come on this page, have the posibility to send the broken url to us and when they have sended to us they see a discountcode.
So basicly i need a submit button that send the current url of the page, and shows a specific code afterward, but without reloading the page.
Who can help me with this?
Basically, you'll need three things to do this:
1) A custom 404 URL that will point to your 404.html page. This is configured based on your webserver-specific configuration, so you'll need to make some changes to point to this page.
2) An Ajax call on your 404 page so that you can make a request without reloading the page.
3) A server-side code generator that can generate and return a unique one-time-use discount code.
The Ajax is pretty easy to do. There are a number of different configuration / frameworks online that allow you to make a request without loading the page. At their core, they usually create a hidden IFrame DOM element with a form inside of it, and submit that form, then close the IFrame. You'll need to tie into this from the parent frame, having the form that submits get sent back the generated discount code from the server. You can then access this data from the parent frame, and display it to the user (probably using JavaScript).
One KEY piece of information to this is that your user could just type in some garbage (ex. http://yourdomainurlhere/oihoaiwhegaweg) and be redirected to a 404 error, and get a discount code. Once this knowledge becomes commonplace, people will always do that to get a discount code; thereby invalidating the reasoning you have for wanting to get the broken URL (in order to fix your site).
You can probably try to get around this by checking for referral links, etc., to try to determine if they actually clicked on a link on your site, or if they just arbitrarily typed in a URL. But this will take much more analysis and possible changes to your entire site to track URL clicking in order to generate the invalid URL.
Related
How would i go about checking if a person is refreshing a jsp page? Could we make it for example that every time we reload a page we would first check if this happens and then we check with System.out.print().
Hmm, first System.out.print is of little use in a JSP because it will never reach the client. At best it will end in the logs, at worst it is lost.
Then in simple cases you can trust the HTTP Referer header that is supposed to give the previous page url. But it is an unreliable way because it may not be transmitted by the browser. A more reliable way is to use a session variable to store the current page (you could use a filter to set it after a request is being processed). If the requested page is the current page, then it is being refreshed.
In complex use cases (AJAX requests) you should first define what is a page, because not every request will constitute a page: some will call a page while some only ask data. But once this is clear, you can apply the previous way: if the user asks for a page which is the current page (as stored in session), then the page is being reloaded.
If you want to do something every time a page load. Then you can use simple javascript for that. Try this
window.onload=function()
{
dosomething();
console.log("Page is loaded");
}
You can learn about it from here.
https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onload
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
How can i get the page URL in single-approver-definition.xml in the e-mail template that is used to send an e-mail to the content creator once the reviewer approves or rejects the submission. The existing xml is as follows:
<template>
Your submission has been reviewed and the reviewer has applied the following:
${taskComments}.
</template>
I tried ${serviceContext.getAttribute("contentURL")} and it didn't work.
I want to be able to do - Your submission for ${pageURL} has been reviewed and the reviewier has applied the following: \n ${taskComments}.\n
Any suggestions will be appreciated.
I don't get what variable exactly you want to process in your notification. As I can only assume, you are using it for Web Contents and all interesting variables are stored in two places.
Workflow context variables - they are available directly. Few examples like:
${taskComments}
${entryType}
${userId}
${userName}
...
ServiceContext variables - they are available using $serviceContext. Few examples:
$serviceContext.getAttributes().get("version")
$serviceContext.getAttributes().get("articleId")
${serviceContext.getPortalURL()}
...
For all interesting variables check this url https://www.liferay.com/web/igor.beslic/blog/-/blogs/workflow-in-action-kaleo-workflow-context-variables Some could change already, however most of them is working fine for current version.
Content changes might be made on a page, they can also be triggered through Control Panel (or the API for that matter). When you're in a workflow, you typically don't have this context any more - if you find it somehow I'd not rely on it to be there. A workflow is unrelated to the UI and pages.
Also, an article might be submitted on one page, where it might be replaced/removed before it's even approved. In that case the link wouldn't help.
What might work is to check the concept behind "Web Content Display Pages" (if your article has them configured and you deal with web content). But the mechanics will vary depending on the actual content type you're dealing with. And content that goes through workflow might not be displayed on any page at all (e.g. when submitted through Control Panel) or on many different pages (either explicitly - Web Content Display - or implicitly - Asset Publisher).
#tomic basically provides pointers to what you have, I'm only reasoning why your initial problem is problematic to solve at best - it's not fully specifiable.
We pull data from server and for that If we are using Struts, then we can pull either by submitting a page which MVC Architecture or we cam make an AJAX call but conventions is of using forms and render response but we also face challenges to give rich user experience, so we compromise convention and start using excessive AJAX, so how we should make balance between two?
I personally think that AJAX should be used for displays updates and form submissions should be done via a page reload. Reasoning?
When submitting forms, you are telling the application to do something. Users tend to want to feel that it was done. When a page doesn't reload, users are often left wondering "Did that work?". Then they have to check to make sure what they did was right.
On the other hand, when you are displaying a chart or something, and the user says to "display 2011 data....now 2012 data" for instance, they aren't "doing" something (creating new entities, sending emails, etc). So AJAX can provide a nice user interface in this case. Page reloads would be annoying here.
In conclusion, I think form submission should be done via page reloads (let the user see it working), whereas display updates should use AJAX (prevent annoying page reloads).
Of course, this is a preference thing. Some of my company's applications use AJAX all over. But those are the applications that are the most difficult to maintain and debug. ;)
Regular old HTML form submission and fancy ajax forms are not mutually exclusive.
First, make the plain HTML form work correctly. Then, add javascript to hijack the form and send an ajax request.
The controller and model don't care if the user's browser supports (or has enabled) javascript. The rendered view is decided by whether the call was made with javascript or a simple form submission. This is one of the strengths of the MVC pattern, not a constraint.
I think that the choice between the two is somewhat intrinsic:
a form submission is synchronous and it reloads the page.
an ajax call is asynchronous and it does not reload the page.
If a certain action will change a lot of UI elements or needs to poll a lot of data to be rendered, I would go with form submission. On the other hand, if a certain action is used for simple actions, like populating a select box or improving user experience, then I would go for an AJAX call.
There is nothing avoiding you to use as many ajax calls or form submissions as you need, so in the end is up to you.
In this day and age, there is virtually no case to use the old standard HTML form submission method (other than pure nostalgia, or perhaps not knowing).
The <form> tags themselves can still be useful if you want to take advantage of the .serialize() function (which grabs all name-data pairs within the form into a query string), but other than that we don't need to use <form> tags at all these days.
Using AJAX, the developer has more control over the entire process, in a more condensed code base. But more importantly, we just don't do things that way anymore.
Consider:
(Old Style - Forms) When an HTML form submits: (a) it gathers the form field name= attribute values (these become the defacto variable names) (b) together with user-entered data in the form fields (which become the variable values), and posts these data-pairs to a PHP file (as specified in the action= attribute on the form tag). THEN, the page changes to that other page, causing a noticeable refresh of the screen and loss of all previously inputted user data. Even using the trick action="", wherein the form data is posted back to the same page it started from, the page is still reset/refreshed.
(New Style) Exactly the same process can easily be programmed using javascript/jQuery - except that the page does not refresh. All previously entered user data/text can remain undisturbed.
Back to your question:
With the old-style HTML form submission, the page changes - so if you want to do field validation you use javascript/jQuery to cut into the submit process, thus:
$('myform#btnSubmit').click(function(){
var some_fields_failed = false;
//check form field values here, set: some_fields_failed = true
if (some_fields_failed){
return false; //halts the HTML Form Submit process and returns control to the user
}
});
in which case you already are using most of the AJAX construct that would replace the HTML form submission process.
This simple introduction to AJAX provides some compelling reasons to use AJAX instead of the old-style HTML Form Submission process:
AJAX is a developer's dream, because you can:
Update a web page without reloading the page
Request data from a server - after the page has loaded
Receive data from a server - after the page has loaded
Send data to a server - in the background
Note that you can write ajax code in pure javascript, but until very recently it was considerably simpler (much less typing, more consistent) to use the jQuery (javascript) library. Hence, all examples above use jQuery. To include jQuery in your project, it is only necessary to include a reference to the jQuery library:
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.2.4/jquery.min.js"></script>
</head>
StackOverflow maven, Schabse Laks, created a simple jQuery tutorial that is worth stepping through (IMPORTANT: Use Down Arrow to step through the pages)
If you have errors between submissions of data the only forms method you could check on the server. On the other hand if you make Ajax calls you could check that errors on the client side. So, out of this different technologies of transmitting data we could follow a decision that they serve different purposes.
When sending a form with AJAX, you generate the POST request and not the browser, so you have more control over it. Even if you don't need that control to begin with, in time it might become necessary.
One case would be protection against CSRF attacks on forms. It can be implemented by adding a hidden form input field containing a CSRF token, which is sent together with the form data. But a preferred implementation would be to add a custom header to the submitted POST request. However, you can't do the latter when using the old form submission method - the browser composes the request and you can't add your own headers.
Whenever there is an error during the load of a JSF facelet, JSF stops rendering the page at the point of the error and shows the error page instead (default behavior). I want JSF to continue rendering a page instead and show the exception/error within the page. For example if the page is loading a "portlet", which throws an exception, that exception would be shown as text within the portlet. I don't want the whole page to be forwarded to a separate error page.
I have initialized my own ExceptionHandlerFactory and ExceptionHandler implementations and I can iterate over the ExceptionQueueEvents succesfully. However, I don't know how to instruct JSF to continue loading the page despite of the error. Is this even the right approach at all? Is the ExceptionHandler called after (as I suppose) or in the middle processing the facelet? If after, is there anything I can do within my ExceptionHandler?
I know I should:
Hide the parts that user cannot access (my specific case relates to security, when user tries to load content he does not have rights to. However, I am looking for a global answer to this)
Manually handle the errors so unexpected exceptions would not be thrown
However, I want the user to be able to continue using the system despite of some minor component failure (for example if some newsfeed portlet throws an error that shouldn't prevent the user from seeing other content and using it).
I am using Mojarra 2.0.2. I feel this is a very simple to solve but I cannot figure it out :(
If your page has separate content, consider using (i)frames. This way, if some particular content fails to load, the whole page would still render, but that frame would show the error page. This of course implies that all your separate components are full html pages.
BalusC is absolutely correct that you should NOT try to handle any parsing exception etc. Oddly rendered page segments are not user friendly, and can lead to very bizarre results.
If you have roles/rights issues, those scenarios should be maintained separate from jsf rendering. Authorization should be confirmed before forwarding to a page, not while attempting to render it.
Doing so would mean that you're giving the enduser a halfbaked HTML page (because JSF hasn't (and can't) complete the HTML rendering) and it's unspecified how the webbrowser would display the page.
Don't do it.