I have created a WebPage A which is called from many different pages. And there is a back button on Page A. So the back button should go to that previous page from where page A is called at that time.
I have already tried PageReference but it is not a successful idea for my problem because PageReferencing needs an int value and if I pass the previous page's reference via page parameter to Page A then it is not sure that last character will be an int value in previous page's reference which can be parsed into integer from string.
You can use plain JavaScript for this:
history.back();
or
history.go(-1);
i.e. Go back. Nothing Wicket specific.
Related
I am new to chrome extension and I am trying to find whether page content got appended.
For E.g. in Facebook, we can see the content will appended automatically when the user scroll down the page.
I have the following code in background.js
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {
alert("page is appending....");
});
The above code is expected to fire when the page got updated. But, I am seeing that it is getting called only for few times. Not always.
Or Am I making any mistake here ?
My requirement is, whenever the web page appended in facebook, I have to do get the page content and obtain few string from the same.
Thanks in advance.
Your onUpdated event is in the chrome.tabs namespace on purpose, it listens the updates of tab's general attributes like: the tab pinned, the favicon changed, the URL changed, see the documentation (also check the update() method). So this way is not workable. Instead listen the DOM tree change with DOMSubtreeModified event or MutationObserver.
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).
I have a classical xPage with view panel (in a custom control) linked to a paginated view, which displays records.
I have more than one page to display. Each one has a key column defined as a link which sends the document to a form edition page.
Then in this page I update the record clicking a 'Save button' which redirects the user to the original view page (which URL has been stored in the sessionScope).
The problem is that it redirects to the first page and not the one which contained the record.
How can I specify the page number to display when coming back to the view page ?
I had to do something similar for one of my applications and instead of using the simple action to redirect to the XPage I used the context.redirectToPage which allowed me to pass the sessionScope variable I had stored with the below code.
var url:XSPUrl;
URL = context.getUrl();
sessionScope.put('your scope name',#RightBack(url.getPath().toString(),"/"));
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
In my page (which displays a list of information), I call a webapage that gets user information and then calls a webservice and a a stored proc for a database on a page (the stored proc inputs or updates a row of data in the db). WHen I click submit, the page is supposed to completely reload the first page with the new updated data and display it to the user. Well, the data does submit to the db, and service, but my page reloads with the old information for some reason, even though I make a call to the entire action that generated the first page. If I navigate back to the home page and then go to the page in question, the data does appear. Should I be waiting or something to call this action again or something?
I do in fact have
[OutputCache(CacheProfile = "ZeroCacheProfile")]
attribute peppered on my actions and in my web.config. Am I missing something? Are there any catches places where I should be carefull when doing this?
I actually recall the entire action that creates the first page.
If you're returning a view directly from the post it may be using the old data. Try redirecting to the GET action to show the results.
This seems to work right now.
Random number = number Random();
RedirectToAction("Action", "Controller", new { value1 = number.Next(0, 100)});
I will go with it for now.