I need a stateless way to implement the back button feature in an ajax forum such that if a user is on page 2 of the topics ajax page, and then clicks on the message - when the user then hits the back button they can go back to the point of the message on the topics ajax page. - your help would be much appreciated.
::Please remember I want a stateless way of doing this, such that it's done client side::
The only option you have is to implement a client-side routing mechanism which you can either achieve by changing the # in your url whenever you change state. For instance your topics page has a url like yourforum.html#topics and whenever a user clicks on a message, you redirect (client-side) to yourforum.html#message/3.
Your JavaScript code should listen to those hash changes and react accordingly by loading topics/messages.
There 2 ways of client-side routing:
changing the hash like in the example I made
HTML5 push-state
Many modern JavaScript frameworks like Backbone, JavaScriptMVC etc... support routing. So you might take a look at those. TodoMVC might be a good starting point. Otherwise try to google for some jQuery plugins which give you this kind of functionality.
Related
The Dynamics documentation is just awful and I couldn't find an answer to this simple question:
In the web version of the CRM, is it possible to register a web page that can be toggled by the user and that itself has an internal state (updated regularly by an interval set with setInterval) that will persist even if the users closes the page (not the entire CRM, just the sub-page)?
We need the user to provide some information for a CTI integration, and this background process to keep alive the CTI session by polling an API while the user session is active. In addition, we need to reuse the component where the user provides the CTI information to be notified if the session fails and restore it or close it if necessary. The real purpose for this is to make a screen pop (push content information about the incoming call to the agent) which I know can be done using Xrm.Utility, although doing it with a REST API method would be much better, RouteTo Aciton looks like the best method to do this, but I'm not sure it will proactively show the item in the user's browser.
I'm not sure this question is as simple as you suggest, it seems relatively complicated, and involves an integration. I'm not suprised the Dynamics documentation doesn't provide an answer for this specific and unique scenario.
I don't believe there is any single feature within Dynamics that will meet this requirement.
You could use a HTML web resource or a web page from a seperate web site iframed into CRM. I think the possible use of these depends on your expected user experience; I believe the user would need to have the page loaded at all times showing these controls (e.g. user is looking at a dashboard) - I don't see how the controls could interact with the user client side otherwise. You could show the controls in multiple places however.
Xrm.Utility is one way to open a record, but it can also be done by Open forms, views, dialogs, and reports with a URL.
RouteToAction looks like it just adds a record into the user queue, the user would need to refresh the queues to see the changes. I don't believe there is any way for a server side REST API call to natively redirect the user.
You could add JavaScript to do this, however you might struggle to add the JavaScript into every page of CRM.
Where I have worked on a CTI integration in the past (assuming you mean computer telephony integration), we always had some other component doing the screen pops - the client's all had a desktop app installed as part of the telephony solution.
Perhaps you could look into browser notifications, or a browser plugin?
I am almost finished with a SPA application using AngularJS and Bootstrap. So far, I got everything working as desired, except for one thing: Proper handling with the users acts on the Browser's back or refresh buttons.
All the sub-pages within the application have buttons/links to the pages the user may switch to. Still, the application should handle properly back and refresh browser buttons. I should add that there is a login process to enter the application.
Also, all the critical information is stored under $rootScope, so everything is lost when the user refreshes and, in some cases, when he acts on the back button the results are not as desirable.
I actually have two questions:
What is the widely accepted standard behavior of applications like mine when browser buttons are acted on? (remember, there is a login process to begin with).
How should I start tackling the implementation of this approach?
One option I was thinking, is to intercept the request, warn the user that the action will log him off, and if the user cancels, force the browser to ignore the request (not sure this is possible).
Client side routing, each view in the application should have a URL. This week allow the browser buttons to work as expected, and gives your users the opportunity to link directly to a view.
The most commonly used client side router for angular is angular ui-router - https://angular-ui.github.io/ui-router
What is the widely accepted standard behavior of applications like
mine when browser buttons are acted on? (remember, there is a login
process to begin with).
If you are using REST services,
Store authentication token in your local storage or in a cookie
When user refresh the page send a request to server and fetch user information
If the request result in 401 then show login screen
This is one of sample applications I have done with this approach.
Can anybody give me a direction, I want to know how to do auto updating pages like facebook have for new status updates, new likes etc. Ie., if you have a status open in a window and a user click "like", the +1 like automatically appears.
Thanks in advance.
These are done using a PUSH model (subscribe / publish).
The client side first subscribes by issuing an AJAX request. This AJAX request stays alive indefinitely. When the server receives a new like / comment, it publishes this update to the client side thereby ending the AJAX request. The client receives this update and isntantly issues another AJAX request.
It is broadly categorized as Comet.
Once before, I had implemented a Comet web chat application and wrote a somewhat technical write up of what went into it. You can read it here, if interested.
Comet Web Chat Application
Edit:
A heartbeat mechanism (PULL model) is definitely easier to implement, but a PUSH model is far more efficient.
You'll need to use ajax, which is a way to communicate with the database without reloading the web page : you could for example use the
$ajax
function of jQuery framework : here's the doc
im not posting code, but here's a quick overview of what you might wanna do:
have the "like" image
create a script that binds a click handler to the image.
once clicked, the script sends an AJAX request to the server to increment the like
if that request succeeds, return data to the script indicating that it was a success. you might also want to return the number of likes and so on.
once the script knows the success, have it change your "like" image.
as for counting likes, well, its up to you. for a very broad question, this is a broad answer that will point you to the right path.
Looking at turning my ASP MVC app into pure JS/Html however its not just a 1 page app, it has a couple of pages, but each one has alot of ajax and events.
Anyway currently my urls on ASP MVC are like:
/login
/admin/{action}/{adminId}
/posts/{posterId}
/picture/{pictureId}
So that is all nice and simple and easy to see what you are doing in the url, you also get correct back button behaviour. So trying to adopt this sort of thing to a pure JS/Html approach seems to bit either very tough or impossible. I dont need an exact match but I was hoping to do something like:
http://localhost/myapp/posts/10
Then that would somehow be able to route the actual request to http://localhost/myapp/posts.html with the variable exposed. Now I am pretty sure this is impossible as when the above is entered into the browser it is going to attempt to look in a directory called posts and look for 10, which wont exist.
Now I have seen Crossroads and LeviRoutes and a few other similar technologies, however they seem to rely upon the hashbang method, which some people like others hate. Is there any way around this? If not can anyone point to any good tutorials on how to use these frameworks, as each seems fairly light on documentation.
There's no workaround for not using hash. HTML5 History API isn't available on IE and Opera yet. If your application is targeting very specific platform, then you can use History API instead of hash. However, History API is inconsistent across browsers. You can read it here: http://www.battlehorse.net/page/2011/02/12/html5history.htm
If you choose to use History API, it would be easy. You can use whatever routing strategy you want in ASP.NET MVC, then just match this strategy in JavaScript. You can read more about History API here: https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
If you choose to use hash, you need to do make some requests into AJAX requests:
Determine if a request is done via AJAX:
if GET/posts/{action}/{id} is by AJAX, serve the original content
if it's not by AJAX, redirect the user to /#!/posts/{action}/{id}.
Handle client side hash by requesting for the right content:
When the hash is changed to #!/posts/{action}/{id}, GET /posts/{action}/{id} via AJAX and replace the content with the new one from the server.
Intercept form.onsubmit event:
Whenever a form is trying to submit to /posts/{action}/{id}, cancel it and use AJAX to post and then replace the content with the new one from the server.
Now your app should work like a one page app.
There is no real way around hashbangs if you wish to keep it clientside and cross browser compatible.
I am writing a web application which retrieves a lot of data using AJAX which substantially modifies the loaded page depending on what button the user clicked (Let's say that clicking on button1 takes the page from state0 to state1 and so on..)
Further, if the button number is passed to the server as a GET variable, the server returns the page in the correct state.
Needless to say, the back / forward browser buttons do not work because the URL is not changed during state changes accomplished through AJAX.
So, my question is, how can I make the browser back / forward buttons work?
Is it possible to supply the browser with the correct URL every time the state changes; but stop the page from reloading?
Please note that this question is only about browser back / forward buttons. I can create custom back / forward buttons but that is not what I want to do.
Take some time to go through some. of. the. previous. questions. on. this. topic.
Hint: use the hash man! (window.location.hash that is)
You will have to use # capabilities of your URL to store your intermediate Ajax requests in browser history. If you use any Javascript library there will probably be a solution in the library itself or in a form of a community extension/plugin.
For instance there's a plugin for jQuery here.
Google for browser history ajax