I inherited a site written almost entirely with AngularJS, and I followed the existing method of busting the cache with plenty of success... until now.
The old method that used to work was simply to increment the urlArgs as shown:
.
I recently made an update and incremented from 2.0.12 to 2.0.13 and it still didn't work as some people were calling support complaining that they couldn't see the updates.
I also added ?v=1 to the end of the require.js:
<script src="bower_components/requirejs/require.js" data-main="app/config.js?v=1"></script>
I'm not sure what I'm missing here. Even the most complicated 'cache-busting' techniques seem to boil down to changing the url arguments.
This is the site: http://vet.vrshealth.com
Related
I have a weird issue with my BigQuery UI (going on https://bigquery.cloud.google.com/queries/my-project-name). I don't know why, but I see no datasets for my projects, when I'm fully aware they exist. My code can still hit these datasets and their tables. There is just no way for me to see them.
In the UI itself, I can still query them if I type the whole query by hand, but being able to see my structure for my schema could be helpful.
When I check my network tab in the developer tools on chrome, I notice that I receive "Failed to load ressource: net::ERR_CACHE_MISS". I then decided to do everything I could to reset my own cache. I cleared my cookies, went incognito, I tried other browsers, even other computers. NOTHING brings back my datasets.
Anyone encountered this and has any ideas how to force my cache to hit?
I had the same problem a while back. When I got the error, I struggled with it and I ended up finding a way to reset this. Seems like it's something cached server-side that makes this incorrect cache-hit. The way to reset the server-side cache is to hit a URL with a project that doesn't exist, so something like https://bigquery.cloud.google.com/queries/bogus-nonexistant-project should reset it all
Did you recently assign a new string ID to your project that previously only had a numeric ID? If so, this is a known issue that has been reported recently, and I'm still working to resolve.
The issue is that the frontend cache gets stuck with the old numeric ID for the project and our frontend JS has a bug where it errors out instead of updating the cache to contain the new string ID. LiY's workaround of going to a bogus, uncacheable URL is the suggested workaround to unstick the cache until this bug is resolved.
(And if you didn't recently assign a new string ID to your project, then I'd love to hear more details about what might have caused this issue so it won't happen to anyone else!)
Is there any way to auto-generate Swagger documentation (or similar) for a Nancy service?
I found Nancy.Swagger, but there's no information on how to use it and the demo application doesn't seem to demonstrate generating documentation (if it does, it's not obvious).
Any help would be appreciated. Thanks!
In my current project I've been looking a lot into this problem. I used both nancy.swagger and nancy.swagger.attributes.
I quickly discarded Nancy.swagger, because for me personally it doesn't sound right that you have to create a pure documentation class for each nancy module. The attributes solution was a bit "cleaner" - at least codebase and documentation were in one place. But very fast this became unmaintainable. Module code is unreadable because of many attributes. Nothing is generated automatically: you have to put path, all parameters, even http method as an attribute. This is a huge effort duplication. Problems came very fast, a few examples:
I changed POST to PUT in Nancy and forgot to update [Method] attribute.
I added a parameter but not the attribute for it.
I changed parameter from path to query and didn't update the attribute.
It's too easy to forget to update the attributes (let alone documentation module solution), which leads to discrepancies between your documentation and actual code base. Our UI team is in another country and they had some trouble using the APIs because docu just wasn't up-to-date.
My solution? Don't mix code and documentation. Generating docu from code (like Swashbuckle does) IS ok, but actually writing docu in code and try to dublicate the code in docu is NOT. It's not better than writing it in a Word document for your clients.
If you want Swagger docu, just do it the Swagger way.
- Spend some time with Swagger.Editor and really author your API in
YAML. It looks all-text and hard, but once you get used to it, it's
not.
- Spend some time with Swagger.Codegen and adapt it (it already does a fair job for generating Nancy server code and with a few
adjustments to moustache templates it was just what I needed).
- Automate your process: write a couple of batches to generate your modules and models from yaml and copy them to your repository.
Benefits? Quite a few:
-
Your YAML definition is now the single truth of your REST contract.
If somewhere something is defferent, it's wrong.
Nancy server code is auto-generated
Client code-bases are auto-generated (in our case it's android, ios and angular)
So whenever I change something in REST contract, all codebases are regenerated and added to projects in one batch. I just have to tell the teams something was updated. They don't have to look through some documents and search for it. They just have their code regenerated and probably see some compile errors, in case of breaking changes.
Do I still use nancy.swagger(.annotations)?
Yes, I do use it in another project, which has just one endpoint with a couple of methods. They don't change often. It's not worth the effort to set up everything, I have my swagger docu fast up and running. But if your project is big, API is changing, and you have multiple code-bases depending on your API, my advice is to invest some time into a real swagger setup.
I am quoting the author answer here from https://github.com/khellang/Nancy.Swagger/issues/59
The installation should be really simple, just pull down the NuGet package, add metadata modules to describe your routes, and hit /api-docs. That should get you the JSON. If you want to add swagger-ui as well, you have to add that manually right now.
No. Not in an automated. https://github.com/yahehe/Nancy.Swagger needs lots of manually created metadata.
There is a nice article here: http://www.c-sharpcorner.com/article/generating-api-document-in-nancy-using-swagger/
Looks like you still have to add swagger-ui separately.
I've been tasked with developing an application for internal use in our company, the end-users being the operators of the call center and their superviser.
There would be therefore be two types of users: operator & supervisor.
The operator view would be purely passive: ability to see their monthly goals (calls taken, calls answered etc) as well as those of their "cell"(group of operators+supervisor) and other "cells" and that's it.
The supervisor one however would be able active: they need to be able to set monthly goals for their subordinates as well as view them.
The application needs to live in the browser, and that browser is...sigh, either IE6 or IE7. So my question is, should I use something client-side like backbone.js, or something server-side like, say, Code Igniter?
I need to be able to develop it in a short time frame and add features as requested.
Any advice is greatly appreciated.
Thanks.
Firstly, IE6 is very old. It is still supported but support will end fairly soon (about a year, I think), so your company needs to have an upgrade plan in place. IE7 has a bit longer to run, but will also fall out of support at some point. Your company must make plans for an upgrade process. And you need to make sure that anything you write today will continue working on upgraded browser versions when they come.
Okay, that aside, today you need to support these browsers.
The first advice I would give is to use jQuery for all your Javascript needs. It is specifically targeted at being compatible with IE6 and above, and it hides a lot of the complexities with cross-browser and old-browser support from the developer, but also works well with newer browsers too.
IE6/7 do have a number of serious bugs and omissions in their Javascript support, but these can generally be worked around. Using jQuery will mean you can forget about most of them.
In the main, I would recommend against using a client-side framework like Backbone. Stick with server-driven simple HTML pages. Maybe a bit of ajax using jQuery, but nothing too much more than that. IE6 and IE7 are very very slow browsers, so the less work you make them do, the happier they'll be. Put too much Javascript on the front end and you could wind up with a system that is too slow to be usable. Also, a lot of modern JS libraries don't support IE6 at all. I'm not sure about Backbone, but even if it works now, you can't be sure that later versions will continue supporting it. (even with jQuery, some developers are starting to push for IE6 to be dropped. I don't think it'll happen just yet though)
Make sure you specify a valid <!DOCTYPE> for all your pages. Without it, IE will drop into quirks mode. This will make it very difficult to upgrade your site to a newer browser later on. There are many valid doctypes, but it doesn't really matter which one you use, as long as it's valid. Therefore, I suggest using the HTML5 doctype, simply because it's valid and it's short and simple: <!DOCTYPE html> -- that's all there is to it.
CSS is where you'll really have some pain if you're used to working with modern browsers. IE6 in particular has terrible CSS support. For IE6/7 CSS compatibility, I recommend using the Quirksmode.org compatibility charts to find out what does and does not work in those browsers.
Finally, make sure you read up on the well known IE6 bugs. There are a lot of them, and they often cause weird and wonderful rendering errors on perfectly valid code. Knowing about them in advance will help you avoid them, and help you recognise them when you (inevitably) hit them.
Hope that helps.
Oh, and good luck -- it sounds like you'll need it! ;-)
Developing websites or web applications for Internet Explorer 6 is possible as long as you do not use things such as HTML5 Javascript functions.
As for the live part, maybe you could use AJAX long polling or something similar. Example: http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery
Hope this helps!
Hi I'm using and Custom ServiceHostFactory, and when I want to update service reference it would'nt work because I assume it needs to setup my servicehostfactory and it will crash.
I have looked for other approaches to not use the generation, but I havent found any good replacements.
Are there anyway to go around this, to not remove the servicehostfactory from the svc files everytime and then put them back there after service reference updates :S.
We use the non generation method described in this dnrtv screencast.
It has worked very well for us. Prevoiously we wasted alot of time due to references not updating or developers forgetting to update a reference before they checked in code.
I rechecked the namespace path and it were wrong in the svc file.
I'm running into a problem with GroupsController::build_acl()- http://book.cakephp.org/view/647/An-Automated-tool-for-creating-ACOs
It's taken me a while to track down the bug and now I've found it I'm not sure how to work around it.
Symptoms:
Not all methods for NodesController (defined by me) are returned.
Probable reason:
build_acl() imports a 3rd party plugin that also has a NodesController and a subsequent App::import() doesn't overwrite it.
I'm about to try two runs of the build, one with the plugin code commented out, but a more durable solution would be preferred!
I need a way to either drop an imported controller or force a re-import while remaining in scope.
you can not do what you want to do, think about straight php for a while. once you have used include('some/file.php'); how do you un-import it? you cant.
now the reason why you cant overwrite it is once again down to php. what happens if you run
<?php
include('some/file.php');
include('some/file.php');
?>
you will get errors about the class being defined already.
Cake is stopping this from happening, so the only (and correct way) is to not have 2 controllers with the same name. you can name them what ever you like and use the router to map to nice urls.
Turns out the plugin was redundant and not called anywhere in the application and would have broken it if it was as a class redefinition error would have ensued. After removal of the files everything worked okay.