Wicket page versioning and history support - wicket

Could anyone explain me what is the Wicket's page versioning useful for? There is an article in the FAQ that is related to this topic:
Wicket stores versions of pages to support the browser's back button.
Suppose you have a paging ListView with links in the ListItems, and you've clicked through to display the third page of items. On the third page, you click the link to view the details page for that item. Now, the currently available state on the server is that you were on page 3 when you clicked the link. Then you click the browser's back button twice (i.e. back to list page 3, then back to list page 2, but all in the browser). While you're on page 2, the server state is that you're on page 3. Without versioning, clicking on a ListItem link on page 2 would actually take you to the details page for an item on page 3.
But unfortunately I don't understand it at all. When I click on a ListItem on page 2, I would expect to get to the page defined by that Link - details page for the item. Why should I get on the details page of the item on page 3?
Moreover, when one press the back button in a browser, it doesn't call the server at all. Is it right?
So how this versioning works?

No, the server is not notified when you press the back button. I'll try to explain what happens in the example:
You access you application for the first time. On the server, a page 'list' is created, used to render the HTML you see in your browser, and stored as page v1. You see the first 10 items of the list.
You click the 'next' link, and it refers to a link in page v1. On the server, page v1 is loaded, the link logic is executed (to advance the pagination), the page is used to render HTML, and is stored as page v2. You see items from 11 to 20.
You click the 'next' link, and it refers to a link in page v2. On the server, page v2 is loaded, the link logic is executed (to advance the pagination), the page is used to render HTML, and is stored as page v3. You see items from 21 to 30.
You click the 'details' link for item 25, and it refers to the link for the 5th item in page v3 (this page only shows 10 items, and the link, even if it refers to the 25th item in the complete list, in this page it's just the 5th). On the server, page v3 is loaded, its logic is executed, page 'detail' is created, stored as page v4, and you are redirected to it. Your browser requests page v4, the server loads it, and uses it to render your HTML page (no new version is stored, since it's just rendering). You see the details for item 25.
You click the browser's 'back' button 2 times, and see page 'list' showing items 11 to 20, referring to page v2 (list). Then you click a link 'details' for item 13. On the server, page v2 is loaded (not v4, the last one executed), since the link clicked pointed to this page version. Then, the 3rd item link's logic is executed, a new page 'details' is created, stored as page v5, and you are redirected to it. The browser requests page v5, the server loads it, and uses it to render your HTML. You see the details for item 3.
All this may seem strange if you come from a Struts-like background, where you always just put the item id or which page to show as a link parameter. In Wicket, the usual case is to store all state in the server, and navigation is not done by the client (direct link to another page passing parameters), but in the server. A link just asks the server to execute code in a page object version, the navigation is done all server-side.
You could argue that the Struts style is simpler (and you can do it in Wicket too, it just isn't optimal), but keeping the state only in the server has many advantages. Fist, once you get used to it, it's actually much easier. No need to add every single param to a pagination link (search parameters, first item, page length, sorting column, order direction, etc.). Also, you avoid many security issues (you can't just change the URL id param to an arbitrary value and access other users' data), and can control everything from Java code instead of mixed Java-Javascript (you still can do it if you want, though).

Related

Pass reference id from url bar to other internal pages

I am compiling a lead generation landing page and, in the form I have inserted a hidden field which collect whatever is written in the url bar after
"?rel=".
This is done in order to track where the leads come from (Facebook ads, direct linking etc).
To be more clear if this is the url: www.mywebsite.com/form.html?rel=fbads
the hidden field will be fill with "fbads" and this is working.
In the landing page I have a link to another page with more details and in this webpage I have the same form.
My idea is to run campaings on the first page with the rel link, but then if the user clicks on the link and go to the detailed page (and then compile the form from there), I am losing the rel field.
How can I pass the rel field to the url of the second page?
Thanks
You may refer the this stackoverflow page. Once the HTTP GET request comes, traverse in HTTP headers in your controller and look for Referer field but it is not always set and the client can change the header value. May be using google analytics is the better option.
If you just want to know that whether if they came to your form page from your landing page or not, you may add fix HTTP URL parameter prior to HTTP redirect.
If you save your rel in a variable, you can add it on your link to detailed page, for example in case of =fbads just once variable is set up, add it: <a href="http://myDetailedPage.com/detailed/?=<?php $rel;?>"</a>

Prevent Component reloading - AEM

I have 2 pages in my web application. Lets say an home page and news feed page. When user clicks a hyperlink on home page then she/ he gets redirected to News feed page. I have 2 separate components in each page like
Home Page --- Header Component & Home Page Details Component.
News Feed Page --- Header Component & News Feed Details Component.
Both the pages has a common component Header. Can I prevent component reloading for the header component when users reaches the second page by clicking link on the first page.
By component reloading I mean the HTML code (HTL) code in the component should not be updated again with updated data instead for the second page, I just want to show the same data associated with header component in the first page.
A new page will always be loaded as a whole, because of just how [HTML] page loads work. What you are looking for is a single page application. They are possible with AEM but are a pain to design, especially the authoring mode behaviour.
This is a very common HTML pattern and possible duplicate of related questions such as: How to auto refresh a section of a page
There are two general approaches, the first being far preferred and supported in various frameworks, all based on JavaScript (AJAX):
Break page into different DIV tags that are independently updated (header separate from body sections, each loaded via AJAX such that only part of the page that has changed is updated).
Use iFrames such that effectively there are different pages - each loaded separately from the other.

What is the best practice for open a new page or redirect page in GWT?

There are some options to open a new page or redirect page in GWT, & I don't know which one is the best?
-Option 1: will redirect the current page to a new page but not opening a new tab.
String url = Window.Location.createUrlBuilder().setHash("!search").buildString();
Window.Location.assign(url);
-Option 2: open a new page on a new tab.
String url = Window.Location.createUrlBuilder().setHash("!search").buildString();
Window.open(url, "_blank", null);
-Option 3: will redirect the current page to a new page but not opening a new tab & retain the states of the previous page
PlaceRequest request=new PlaceRequest(NameTokens.search);
placeManager.revealPlace(request);
In Option 1 & 2, it seems that the system starts to reload the whole page. For option 2, if you press Back button then it will reload the previous page again.
In Option 3, it seems that it does not reload the whole page (ie if you have a header then it won't download the header again). Therefore, it run very fast. If you click Back button then it won't reload the previous page so you can still see all the existing states of the previous page.
Option 3 is quite fast. However, we need to properly reset some variables in the previous page otherwise it will make thing really messy and error-prone.
What is the best practice for open a new page or redirect page in GWT? Which option should we use?
Option 1
Whenever you reload the page, your app has to reload as well. It may happen fast, as the browser caches your code and other static elements, but what is the point? GWT is used as an "app": it resides within a single host page, and changes its state based on user instructions.
Window.Location.assign(url) is only used when a user is leaving your application: either because this user logged out, or because he is not logged in yet, and you redirect him to a login page.
Option 2
Usually, this option is used when you provide a link to a different application/website, and you want to keep your app running.
Option 3
In this option you do not "redirect" "pages". You show different "views" to a user. The web page (host page) remains the same at all times. This is how GWT is supposed to work.

passing variables into new page tab installations

I would like to build a customized Facebook page tab for other page owners to instal onto their Facebook pages. Each page tab will need to have its own ID in the links that lead out of the page tab in order for us to track that page activity.
For example each page tab will have a list of products that link to the relevant product pages on an external website. Each of those links will have a unique ID parameter to we can track clicks and purchases. [e.g http://www.mydomain.com/products/product123.aspx?userid=12345]
So I need to create the userid variable in the link. Possibly using GET (or Request.QueryString for asp) to receive from the initial page tab installation.
From what i can see I might be able to use the app_data parameter to pass data over to the page, but when i tried it, it didn't work.
This is what i am using to install the page tabs
[https://www.facebook.com/dialog/pagetab?app_id=YOUR_APP_ID&app_data=12345]
I thought that this will pass the userid over to the new page tab, but it doesnt seem to work.
If anyone could point me in the right direction i would be very grateful.
Cheers
From what i can see I might be able to use the app_data parameter to pass data over to the page, but when i tried it, it didn't work.
This is what i am using to install the page tabs [https://www.facebook.com/dialog/pagetab?app_id=YOUR_APP_ID&app_data=12345]
But you are aware, that appending &app_data=12345 does not mean you will get a GET parameter by the name 'app_data', right …?
The app_data will be passed as a property inside the signed_request parameter – so you’ll have to decode that one, and inside you’ll find your app_data value.
Why does 'each page tab' need to have an ID?
The Page ID should be enough for you to determine which content to show (and it's passed to your app on each page load via the signed_request, and the page ID is also passed back to your app in the callback to the pagetab dialog
You could also request manage_pages Permission from the user to determine the list of pages they administer and if your app is installed on each

Facebook: Custom Landing Page "For Fans"

Facebook provides us with an option to choose a custom landing tab for the new visitors (i.e. non-fans). Can we have a custom Landing tab for fans so that every time i open the page, i m directed to that custom page rather than the Wall..
Have you checked Facebook Help Center?
How can I select a tab as default for people who already Like my Page?
This functionality does not exist.
What you are trying to do is straightforwrd.
Create a "landing page" tab app and add it to your page. Here is a tutorial on how to do it: http://how-to-create-facebook-app.koliber.com
Make this tab the default for your app. On your page, in the upper-right corner click "Edit Page" and change the "Default Landing Tab" to the one you would like displayed by default.
Now everyone will be shown the default tab when they log in. How to distinguish between those visitors who "liked" your page and those that didn't? Easy. Make two versions of the page and display one to those who liked and one to those who didn't like. How to find out whether the current visitor liked your page or not follows:
When your Page Tab URL is called in the iframe, it is passed a signed_request POST parameter. This parameter contains the info you need. However, it is encoded and structured so it needs some processing to get the info
Split the signed_request on the '.' character. The first part is the signature. The second part is the encoded_data
Decode the encoded_data into a JSON string using the URLBase64Decode function equivalent in your server-side programming language
The JSON object contains a node called "page". This contains a node called "liked".
If "liked" is true, the user liked the page and you display the "liked" version of your app. If false, show the "Please like me" version of the site.
This way, when visitors visit your page, they see your custom app in a tab. The actual content is determined server-side on your server based on the page.liked property inside of the JSON object passed to you in signed_request
The simple answer as far as I have been able to find out is "No". There is no setting which aligns with this requirement.
The wall is the default tab for people who like the page.
http://apps.facebook.com/static_html_plus/ this application gives you those options... enjoy!