Background:
I have a web app that references many CDN's in my HTML front end. Full disclosure, I am a novice dev at best so very likely that the answer is very simple.
At the time of writing (Oct 2020), I am using, among others, the following CDN:
<link href="http://cdn.pydata.org/bokeh/release/bokeh-widgets-2.0.2.min.css">
Question:
Is there a more dynamic way to link this CDN so that I don't have to manually update the version number (2.0.2) if and when it changes?
If your question is:
How can I ask Bokeh itself for the matching CDN links that correspond to the current installed Python package version?
Then this is the simplest way:
In [1]: from bokeh.resources import CDN
In [2]: CDN.js_files
Out[2]:
['https://cdn.bokeh.org/bokeh/release/bokeh-2.2.1.min.js',
'https://cdn.bokeh.org/bokeh/release/bokeh-widgets-2.2.1.min.js',
'https://cdn.bokeh.org/bokeh/release/bokeh-tables-2.2.1.min.js']
Note that that just lists all possible resource URLs. If you aren't using widgets or tables then you don't need those files.
Also note:
The official URL changed to cdn.bokeh.org several years ago. The "pydata" links will continue to work, but everyone should prefer the bokeh.org ones in any new code.
There are not any separate CSS files any more in recent versions of Bokeh, on the JS files.
The above assumes you are using Bokeh from Python, where the Python and JS versions need to be matched. If you are using BokehJS directly (not super common, but it happens) then you should just pick whatever version you intend to use, and update it intentionally/manually, as others have suggested.
A very similar question has been asked before on this subject here
Getting the latest version from cdnjs
and it's generally not a good idea to adopt this practice.
Always using the latest version can expose you to bugs, unwanted behaviour. If the version you are using is stable, then its probably best to stick to it.
Related
I am quite new to Mediawiki and am trying to get templates work.
I managed to get a simple one working but the templates are shown in a weird way but no error is provided.
I looked at your template:
http://wordpress-251650-782015.cloudwaysapps.com/index.php?title=Template:Cita_conferenza
And it invokes a LUA module:
http://wordpress-251650-782015.cloudwaysapps.com/wiki/Modulo:Citazione
You can read more information about using this module on
https://it.wikipedia.org/wiki/Modulo:Citazione
#Revious
A bit late, but you may still be interested...
If you want to copy a template from Wikipedia, but it is using lua modules, you can look in the history tab to find pre-lua versions that use only wikicode (lua has been implemented in 2013 in Wikipedia, but some templates have been given modules later).
Here, it seems to be this version
Be careful, however, if the template you are copying uses subtemplates (this does not seem to be the case here).
If this is the case, you should either make copies of the templates with the same name and code, or add their code to the main template, paying attention to the parameter names which will need to be adapted.
Good luck.
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I'm using primefaces and primefaces-extensions in my application. For each and every resources like .css and .js files there's also an "ln" and "v" query parameters in the GET request for that resource, like below:
primefaces-extensions.js?ln=primefaces-extension&v=6.1
validation.js?ln=primefaces&v=6.1
As a security concern, since these parameters shows the exact version of the framework I'm using, how can I hide them?
Hiding the 'ln' is kind of useless since with a very small amount of effort, you can get the same information from the javascript files and the source of the page too ('PF() is all over the place)
The 'v' however is a slightly different issue. If you use the non-modified PF source, hiding it is sort of useless too since with very little effort (creating a hash) the possible hackers can download your sources, create a hash and compare the resulting hashes with a dictionary they can easily create of existing PrimeFaces sources and then know which version you use. So the only thing to do here is to modify the source to have it not turn up 'known or comparable' hashes by making some slight modifications (adding whitespace should already help).
But if you really want the version not to be show, you can download the PrimeFaces sources and replace the version info with some ofuscated number and build that custom version. Keep in mind that if you don't make any changes in the sources, the dictionary lookups mentioned above are still working. So it is only some minor inconvenince for hackers.
I just came across Twitter Bootstrap today, on SO. I have skimmed through some online tutorials and if my understanding so far is correct, using the TB essentially consists of:
Downloading TB, extracting CSS files etc
Referencing the required CSS, JS files in your HTML doc and using the defined CSS patterns
I want to use Twitter Bootstrap with Symfony2. Given my understanding of how to use TB I thought it would be relatively easy to use it with Symfony, so I was quite suprised to see that there are (actually several) Bundles to use with Symfony.
So my questions are:
Why is a Bundle needed to use Twitter Bootstrap with Symfony2? - will the method I explained above not work (i.e. adding the references directly in a twig template)?
Since there are several Twitter Bootstrap Bundles available (at last count there are 3), which is the easiest to use (it has to be one that is actively supported with recent commits, and not a dead project)
I'm pretty sure these Bundles are great, but they have advantages and drawbacks. You could also use TB without a Bundle directly in your project. That's what I personally do, that way:
git clone TB in web/ (to get latest updates and keep updated)
I directly call bootstrap.less in my twig templates with Assetic and the less filter. That way, I can create my own .less files that #imports TB and use their astonishing mixins for example.
It's really powerful this way. Coupled with yui-compressor, when I use Assetic in no-debug mode, all my js and less files are compiled into one single .css output and one single .js output. And you could benefit from all TB functionalities, in .less, not .css
There are 2 major bundles that provides symfony integration with Twitter Bootstrap:
MopaBootstrapBundle
BcBootstrapBundle
In my opinion:
MopaBootstrapBundle is more complex, provides its own layout structure (of cause you can create your own too) and lot of defined functionality, extra assetic, forms and other integration
BcBootstrapBundle is more simple and much more clear you use your own layout structure and there is a lot of defined functionality, extra assetic, forms and other integration too
dont use any intergtaion bundle also is an option, but you loose integration with forms, assetic, less and so (as #Acyra mentioned in his comment)
I prefer to use BcBootstrapBundle with its extra integration functionality and use my own custom layout structure.
You can use Twitter Boostrap (TB) to only add css to your project. And then, you have a starting point to do something more visual than started from scratch. As you described in the first part.
But, you can also retrieve more interesting stuff from a Bundle which handle template integration with TB. For example:
having a default layout that set some basic column
integration for crud generation
having a basic form element
For example, with symfony 1.4 (I know this post talks about sf2), you have a plugin that can add a new theme to the admin generator to have a nice TB integration instead of the default. I know there is no official admin generator in sf2 but it can be used for CRUD.
One other thing that can be true since symfony 1.0, not all bundles are very well implemented, developped, maintained, tested, documented, etc .. (except thoses from the core team (FOS* Bundle, Doctrine, Propel, etc ..)). So I recommend you to test them all, see if one of them fit your need, otherwise take inspiration to improve them (they are almost all on github) or build your own.
And btw, there are many Bundle ..
UPDATE to Symfony and Bootstrap: Symfony always seems a little behind in the details of their documentation so here's an update on Symfony. Version 2.6 and greater now includes basic integration with Twitter Bootstrap.
http://symfony.com/blog/new-in-symfony-2-6-bootstrap-form-theme
Hopefully this saves someone time and can get it to work as they explain in the Symfony documentation above!
I want to give credit to all open source libraries we use in our (commercial) application. I thought of showing a HTML page in our about dialog. Our build process uses ant and the third party libs are committed in svn.
What do you think is the best way of generating the HTML-Page?
Hard code the HTML-Page?
Switch dependency-management to apache-ivy and write some ant task to generate the html
Use maven-ant-tasks and write some ant task to generate the HTML
Use maven only to handle the dependencies and the HTML once, download them and commit them. The rest is done by the unchanged ant-scripts
Switch to maven2 (Hey boss, I want to switch to maven, in 1 month the build maybe work again...)
...
What elements should the about-dialog show?
Library name
Version
License
Author
Homepage
Changes made with link to source archive
...
Is there some best-practise-advice? Some good examples (applications having a nice about-dialog showing the dependencies)?
There are two different things you need to consider.
First, you may need to identify the licenses of the third-party code. This is often down with a THIRDPARTYLICENSE file. Sun Microsystems does this a lot. Look in the install directory for OpenOffice.org, for example. There are examples of .txt and .html versions of such files around.
Secondly, you may want to identify your dependencies in the About box in a brief way (and also refer to the file of license information). I would make sure the versions appear in the About box. One thing people want to quickly check for is an indication of whether the copy of your code they have needs to be replaced or updated because one of your library dependencies has a recently-disclosed bug or security vulnerability.
So I guess the other thing you want to include in the about box is a way for people to find your support site and any notices of importance to users of the particular version (whether or not you have a provision in your app for checking on-line for updates).
Ant task seems to be the best way. We do a similar thing in one of our projects. All the open source libraries are present in a specified folder. An Ant task reads the manifest of these libraries, versions and so on and generates an HTML, copies into another specified folder from where it is picked up by the web container.
Generating the page with each build would be wasteful if the libraries are not going to change often. Library versions may change, but the actual libraries don't. Easier to just create a HTML page would be the easiest way out, but that's one more maintenance head ache. Generate it once and include it with the package. The script can always be run again in case some changes are being made to the libraries (updating versions, adding new libraries).