I was trying to build a simple auth mechanism using madvoc and interceptors but it seems that the tutorial at
http://jodd.org/doc/example/auth-with-interceptors.html
is a little bit outdated.
I think that the tag was removed and I was not able to find the substituent.
How should we use the form in general and what is the recommended auth mechanism?
P.S. - I`m using latest jodd version.
The shortest answer is to check module jodd-joy. Look at the package jodd.joy.auth. It contains latest AuthTag, AuthAction that may be used, etc. This module contains some helpers for build an web-app even faster.
I will update this answer later, with more info - actually, I will try to update the website, too. But in general, the idea behind the auth is not much changed;)
Related
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.
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!
Is there a recommended way to extend the nut interface of bolt cms?
I would like to implement an extension for bolt which is best triggered from commandline but couldn't found any kind of documentation about this matter.
My current idea is to just edit the app/nut file and load my own BaseCommand subclass but before that I would like to know if there is another intended way
Yes, there is. Well, there will be...
Currently it is committed to master and will be in Bolt 2.0. You can see the draft documentation that I wrote that explains the process... Really simple :-)
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!
There are so many template engines for node.js and express and there is even this detailed comparison: http://paularmstrong.github.com/node-templates/index.html This led me to check out EJS, Mu2 and JQTpl and I spent some hours on experimenting which of them fits my needs best.
I know that there already are several questions concerning which framework is best, but none of them concentrates on the possibility of using helpers. I tried to build a form helper (which should render input tags and their values if I pass an object into it) together with all of them but I did not find a straight forward way accomplishing it.
Are there any recommendable modules that enable me to use helpers? Maybe even using mustache.js (which - for me - feels like the best of the ones I tried)? Thanks in advance!
I can't point you to the comparison you are looking for, but nearly all the templating engines I've looked at have had a facility for helpers.
If you are using Express (which you mentioned in your question), you can tell Express what helpers you want to expose to whatever template engine you are using (set via the "view engine" app variable) - see the following sections of the Express Guide for details:
View Rendering - explains how to configure Express to use a particular templating engine. The example refers to Jade, which is installed with Express by default, and does support helpers.
Server.helpers() - How to register static view helpers to be passed to your template
Server.dynamicHelpers() How to register helpers which can access the Request and Response objects
Some template engines come with support for Express built in, although they may require an extra configuration step. I am partial to CoffeeKup (and the more updated fork coffeecup), which lets you write your views in Coffeescript; enabling auto-compilation requires and extra call to the Express server object (and covered in the docs):
app.register('.coffee', coffeecup.adapters.express);
Others may offer an additional node package, you may find npm search express- instructive. For example, express-handlebars specifically fixes up app.helpers() and app.dynamicHelpers() to work with handlebars. (Disclaimer: I haven't used this module personally).