I have a simple OAuth verification set up using Backbone, and it's working fairly well. My question is somewhat nitpicky (though... I am also new to Backbone), but I'm hoping to find somebody who might know how to solve this.
I have a Session model which, at initialization, sets a #authenticated value based on the presence of a value in localStorage. There's also a method in here, authenticate(), which checks the #authenticated value for pass/fail. If the value check fails, it uses my router to navigate to the login route. If the value check passes, an optional callback passed in by the user is run.
In my main AppView (the first View run at application start) I run Session.authenticate(), and if it passes, route to "#home" (and my Router handles loading additional Views).
My question is this: as an un-authenticated user, if I type http://url.com/#home into my browser, I am successfully routed to "#login", but if I bring up my DevTools, I can see a request being made for an image in my "HomeView" view. What am I not understanding about how Backbone flows through this process? Shouldn't the route for "#home" not even run until after the application initializes, and therefore not even attempting to load the "HomeView"?
What kind of templating engine are you using? If your templates are for instance inline, inside the HTML template where your backbone app lives, then I believe any images inside those are rendered when the page loads. I may be wrong. Also, ensure your HomeView is not running by logging something to the console in the view's initialize method.
Related
My application is built on Angular 5 and we are using Office.js for interacting with MS office word document.
Step 1: Invoking office displayDialogAsync to load the component.
Step 2: Within the attribute-users component, I am invoking HTTPS GET to get all users based on the search term
Step 3: The angular service uses HttpClient (this.http) to call the service
However, the call errors out and prints this error message on browser console
Note - If the attribute-users component is called via angular router (this.router.navigate) instead of loading it in office.js dialog, it works fine! Also, for above issue, the http call is also not seen in network traffic.
Any thoughts on what am I missing here?
(Deleted my original answer in light of the OP's clarification that he is using HTTPS.)
New answer:
When you open an Office Dialog, you are opening a completely different instance of the browser and its JavaScript runtime. When you pass a route from your Angular app to the dialog, you are launching a completely separate instance of your app in the dialog. I don't recommend this. I recommend that you create a simple HTML page to launch in the dialog, even though this technically means you don't literally have a "single page" app anymore. This page should do very little. Just get the access token and pass it back to the parent page, usually a task pane page, with the messageParent API. Everything meaty in the app should be happening in the parent page. This would include your getUsersFromIcmM and getIcm.
If you don't take my advice in #1, then here's a troubleshooting step you should take: Assign a handler to the DialogEventReceived event and see what error message you are getting. For details see Errors and events in the dialog window. (And, if you haven't already, read the whole of that article.)
For various reasons I will not go into, I have successfully wrapped the ITHit Ajax File browser inside of an Angular Controller, which itself is loaded and wrapped in an Angular-UI-Router UI-View.
All of the settings are configured through preceding service calls (to support a cloud environment with shifty urls), and I've even gotten through all of my CORS (Cross Origin Request) issues, and we've wired in a custom Oath2 implementation on the DAV server. All of this is successfully working with the ITHit File Browser as a pretty centerpiece for our content-browsing implementation.
As of now, when I navigate certain areas, the Angular-ui-router tweaks the Url, the view responds, and the Angular Controller wrapping ITHit responds to the view change, and (without reloading the view) re-fetches the appropriate DAV url with available IT Hit commands ( e.g. SetSelectedFolderAsync )
Here's my (hopefully simple) challenge: when I navigate to certain areas - Angular-UI-router simply reloads the containing UI-View with new content, but when I return - the ITHit Ajax File Browser does not redraw.
Here are some guidelines to my challenge (ignore-able if you offer something I can work with):
I'd prefer to avoid having to "hide" the ITHit container (because
it's irrelevant and I don't want to have to manage keeping it up to
date as state changes in the view. These changes affect DAV paths). Also I don't want to worry about unnecessary network traffic.
I'd really like to let Angular-UI-Router do its thing with the
ui-view in which the browser is resting.
I'd like to keep
whatever calls need to be made invokable to the Angular Controller
(it's managing authentication, path resolution, and contextual
settings config - which change as users navigate).
Everything (well most important things) generated by the ITHit solution is
stored in a Singleton ('DavBrowserService') - so when I return to
the file-browser view, I have everything stored from the initial
instantiation including:
an instance of ITHit Object
the produced instance of the ITHit.Loader
an instance of the previously produced AjaxFileBrowser.Controller Object (ITHit.oNS.Controller)
an instance of the previously produced WebDavSession Object ( ITHit.oNS.WebDavSession)
With the above in place - I'm hoping that I can simply re-wire these instances back on to the now-returned dom-node ('afb-content-div').
Any help is MUCH appreciated!
UPDATE: The below "answer" while appearing to be functional - indeed was NOT. However, I have worked around this issue by grabbing the DOM instance and storing it memory when the user navigates away, and re-attaching it after the user has navigated back to the appropriate area. This way all of the ITHit Magic is still tied to the right DOM node, and I don't have to worry about the partial re-instantiation weirdness. Seems to be pretty solid now.
I figured it out!!! It looks like if I re-instantiate the controller by calling:
var controllerInstance = new ITHit.oNS.Controller( originalSettingsObj );
Everything rewires magically! I've wrapped the above code with some detection for whether the 'afb-content-div' HTML DOM node has children.
After much digging in the code, it looks like this is the argument object returned to as a parameter to ITHitLoader.oninit callback (From the AjaxFileBrowserLoader instance).
Thanks for playing!
The node.js server has two roles:
RESTFul API on routes with prefix /api
Renders website pages on the others routes (/ /plans /features /terms ...)
For the moment, all my pages render a "Loading page..." combined with the Backbone application that replaces the DOM when the Backbone.router starts.
I would like to build the website pages server-side when an user reaches a page and let Backbone handles the next part of the navigation when the user navigates on the website.
I know how to do it server-side but client-side when a page is loaded with the DOM already built, the Backbone.router loads and then replaces the DOM because it does not know that the view is already preloaded.
How to fix it client-side?
Code:
The router: http://pastebin.com/aUuXaVm9
Home view: http://pastebin.com/qS1tHUfq
Terms view: http://pastebin.com/et1mrbLK
Update: the new code: https://gist.github.com/mathieug/d50c861e63dd647f1c2b
Now I need the runSlider method to be called at the first load.
When you start the History, make sure to pass {silent: true} as an option to let Backbone know that you've already loaded a complete page. This will prevent the router from replacing the DOM when the view is already preloaded (the first time).
From the Backbone.js docs:
If the server has already rendered the entire page, and you don't want the initial route to trigger when starting History, pass silent: true.
So, your code should look like:
Backbone.history.start({pushState: true, silent:true});
So, this is not that simple to explain, but I have my Ember app, with my routes, controllers and views etc, it's about jobs listings, this is the most important part of the app, but I also have other models, for users and companies. So, in the ApplicationRoute I'm doing this thing here:
renderTemplate: function() {
this.render({ controller: 'jobs' });
}
because on my jobs controller I need to count the amount of listings I have, to display in a menu that shows up at every page, like this:
I'm getting this number by doing this at the jobsController:
jobsCount: function() {
return this.get('model.length');
}.property('#each')
which works fine because my homepage is the listing of jobs, which calls /api/jobs/ with all of them. The problem happens when I start the app in any other page, like accessing /jobs/:id/ directly, /admins/ or anything else, the count would be zero, since the jobsController is not loaded and I don't get the number of jobs from the api (accessing /api/jobs/:id/ directly, for example). After accessing the homepage the number of ads load, since it calls /api/jobs/ with all the jobs on it. So, one of the workarounds for this was setting ApplicationsRoute's model to be jobs as well, which resulted in two requests every time the application loads for the first time, that was working fine but I don't like the idea of having to do two requests just to get a number, especially when most of the time the first page to be loaded is the homepage, resulting in two requests to the same URL (/api/jobs/).
Is there anyway to do this without doing two requests, like if I visit a job listing (/jobs/:id/) to force it to load /api/jobs/ and then look up for the id, instead of loading /api/jobs/:id/, or this is not a good solution as well? Should I have a specific URL on the API just to load this numbers?
Is the question clear enough?
Thanks.
I had a similar problem and ultimately I decided to break DRY. In your example this would mean rendering the job_count in the json rendered by all routes that could possibly be called when the user enters the application. This makes the app's design slightly messy, but means that you never have to make multiple calls.
However, if your app gets to where there is a lot of unrelated data that ember needs access to when the user first loads the app, then you should make a url specifically for loading that data and yes, make two requests upon initial load. As far as UX goes, a marginally longer initial load time is irrelevant because of the improvement ember gives for every route entered there-after. Remember, by rendering client-side ember will always be slower upon initial load than a traditional server-rendered app anyway.
I'm afraid that's trade-off that has to be made.
I would do it something more like this. In your JobsRoute, you can do something like this:
App.JobsRoute = Ember.Route.extend({
model: function(params) {
var jobs = this.store.find('job');
jobs.then(function() {
this.store.find('job', params.job_id);
});
}
});
First, we'd find all the jobs by calling this.store.find('job'). This will return a promise, which we wait for it to resolve and populate the store with all the jobs. Then, we find the job in particular we're looking for. This way all the jobs are loaded, in just one request, and only one job is represented by your job controller.
I have a grails application where i have to detect if page is rendered successfully.
So, if I have render view: "mypage", I want to know if this page was rendered successfully by tomcat. Whether it reached user or not is not concern here. That is another part which can be tracked by using javascript events.
The solution that comes to my mind is using error controller and url mapping to map any issue like 404 or 500 to one controller but that controller is somewhat generic and will be handling multiple issues and not just this one.
So, Is it possible to exclusively know for this render call if it was rendered properly or not?
Try attaching a filter to the action with the afterView filter type. The documentation mentions that the first argument is an Exception, so if the first argument is null, then the render succeeded. (Also note that the documentation mentions afterView is called before the SiteMesh layout is applied, if that matters for this particular problem)