I'm using DNN 6.2.5 and the versions of NB Store available for download are not supported. So, can anyone please give me a link where I can download NB Store supported for DNN 6.2.5
You can try this:
https://nbstore.codeplex.com/SourceControl/changeset/4010100c027b57e166ac309eeded09325d134343
Comparing the dates of publication of the NB_version and DNN 6.2.5 version seems it should work.
Related
When submitting Excel add-in to the office store. Which version of the Excel API should be referenced in the manifest file?
We have experienced being rejected because we didn’t refer to the newest version of the Excel API.
But if our Excel add-in supports an older version of the API. Shouldn't we be referencing this?
There are several aspects to the versioning of the Office.js library.
First, there is versioning of the actual JavaScript source files. Fortunately, this part is pretty simple: you always want the latest and greatest of the production Office.js, which is conveniently obtainable through our CDN: https://appsforoffice.microsoft.com/lib/1/hosted/Office.js. The files are also shipped as a NuGet package to allow corporate firewalled development, but the NuGet may lag a few weeks behind the CDN -- and in any case, any Store-bound add-in is required to reference the CDN location. So, in terms of Office.js versions, there isn't really versioing there: there is simply the one and only evergreen, frequently-updated, always-back-compatible, Store-required CDN version.
(While on the subject of CDNs: we also have a beta CDN, available at https://appsforoffice.microsoft.com/lib/beta/hosted/Office.js. This one is great to testing newly implemented-but-not-yet-officially-stamped-as-done features, which you'll find in our Open Specs: http://dev.office.com/reference/add-ins/openspec. However, any new APIs therein should be considered as strictly "beta", and they may well be renamed, re-grouped, or postoponed -- so your app should not rely on them, as we explicitly reserve the right to break pack-compat on the beta branch. An API is not "done" until it is listed in IntelliSense ande Documentation as complete, until it's available on the Production CDN, *and until its isSetSupported returns true -- more on that momentarily).
The more interesting bit for versioning are the actual API capabilities that are offered by each host. The Office.js library will have the latest JS code to be able to run them, but older hosts might not be able to support some of the functionality. For example, if you look at https://dev.office.com/reference/add-ins/requirement-sets/excel-api-requirement-sets, you will see that the 2016 wave of Excel APIs -- grouped under the "ExcelApi" requirement set -- has had three versions to date: 1.1, 1.2, and 1.3. ExcelApi 1.1 was what shipped with Office 2016 RTM in September 2015; 1.2 shipped in early March 2016; and 1.3 shipped just recently, and is in the process of being rolled out to the CDN. Each API set version has a corresponding Office host version that supports this API set (for most APIs, there have to be both JS and host-side changes; it's fairly rare that something can be a purely-JS addition). The version numbers are listed in the table, and there are links below the table to find a mapping from build numbers to dates.
Each of the API set versions contain a number of fairly large features, as well as incremental improvements to existing features. The topic for each requirment set, such as the link above, will provide a detailed listing of each of those features. And as you're programming, if you are using the JavaScript or TypeScript IntelliSense, you should be able to see the API versions for each of your APIs displayed as part of the IntelliSense:
You can use the requirement set in one of two ways. You can declare in the manifest that "I need API set ExcelApi 1.2, or else my add-in doesn't work at all" -- and that's fine, but then of course you aren't able to service older hosts, and so your add-in won't even show up there. Alternatively, if you add-in could sorta work in a 1.1 environment, but you want to light-up additional functionality on newer hosts that support it, you can use the manifest to declare only your minimal API sets that you need (e.g., ExcelApi 1.1), and then do runtime checks for higher version numbers via the isSetSupported API. Neat ways to get environment (i.e. Office version) has a very detailed explanation of this isSetSupported API-checking.
Hope this helps!
Is there a way to get all versions and related File of single document
Suppose that I have published document 'abcd' with version 1.0. Then later, I modify the document and publish it with 1.5 and i want both version in java so is ther any possible way to get all documents with diffrent version in nuxeo.
Yes, CoreSession.getVersions will do that for you. There are also variants of this API that returns just document references or a bit more information related to each version. You should peruse the CoreSession API to know more.
I recently learned that there are a plethora of WebSocket protocol specifications (a bunch of them named hixie-, another bunch of hybi-, and finally a RFC 6455).
I assumed that hixie- and hybi- were previous drafts, and that the RFC is "the final word" towards all the implementations will eventually converge. However, I was surprised to discover that the RFC is from December 2011, while the latest hybi-* is from February 2012.
Could someone please shed some light? What is the historical development of all those branches and what is the roadmap for the future?
By the way, do those funny names (hixie and hybi) stand for something?
"Hixie" stems from Ian Hickson ian#hixie.ch .. original proposer/author of the WebSocket protocol.
"Hybi" stems from "hy_pertext bi_directional" .. IETF working group "BiDirectional or Server-Initiated HTTP (Active WG)".
The latest and final RFC is RFC6455. Do implement that.
Hixie-75/76 are deprecated, security flawed, outdated versions that were in use for some time.
Hybi-Draft-N .. where N is .., 10, .., 18 mark revisions of the protocol during the development of the final RFC from draft RFCs.
Everything >= Hybi-10 are only small variants of the final RFC6455.
In short: read and implement https://www.rfc-editor.org/rfc/rfc6455 and you will be fine.
I'm using Go for Google App Engine, which uses an older version of Go. I want to use a third party package that requires a newer version of Go (goauth). It is possible to use that package in my Google App Engine program?
Goauth uses strings.SplitN, which does not seem to be present in the GAE version of Go.
Not without hacking the source of oauth to make it compatible, I'm afraid.
Either that, or you can try and contact the author to see if they are willing to publish a version compatible with AppEngine's Go version.
A third option would be to find an older revision of oauth which is compatible with your Go version and just use that one.
Does anyone know of a good online resource which gives a clear reference on the SQL syntax supported by HTML 5 client-side databases? I've looked about and cannot seem to locate one.
Thanks
This is still a working draft, but you can read more about it here - http://dev.w3.org/html5/webdatabase/
You might be interested in this too - http://net.tutsplus.com/tutorials/html-css-techniques/quick-tip-learning-about-html5-local-storage/
the short answer: http://sqlite.org/lang.html
the long answer: the sql-syntax isn't in the spec, because it's entirely defined by sqlite, the db-engine used by both safari and chrome (the two browsers to support webdb, with opera probably following soon(ish) and ms and mozilla refusing to follow just because of the fact that such a spec would be too dependant of the evolution of an external component). so you'll probably want to look at the sqlite sql dialect?