1642073040

Cookiecutter-flask: A Flask Template for Cookiecutter

cookiecutter-flask

A Flask template for cookiecutter. (Supports Python ≥ 3.7)

See this repo for an example project generated from the most recent version of the template.

Use it now

Docker (This is the preferred method for creating a new project)

# Basic usage (You will be prompted to provide basic information about your application)
$ ./cookiecutter-docker.sh
    full_name [Steven Loria]:

# Additional arguments are available
$ ./cookiecutter-docker.sh --help
    Usage: ./cookiecutter-docker.sh [OPTIONS]

Options:
    -b, --build    Build Docker image before running cookiecutter
    -t, --template Specify custom cookiecutter template via a URI to a git repo
                    e.g. https://github.com/cookiecutter-flask/cookiecutter-flask.git
                    Defaults to template in current working directory
    -h, --help     Show this message and exit

Standard

If using standard instructions, Python ≥ 3.7 is required. A virtual environment is recommended (like virtualenv).

pip3 install cookiecutter
cookiecutter https://github.com/cookiecutter-flask/cookiecutter-flask.git

You will be asked about your basic info (name, project name, app name, etc.). This info will be used in your new project.

Configure and Run

After you have generated the project code, a few more steps must be taken before your new app will run. The README of the generated project shows you how to configure and run the application. (You can see the template README here).

Features

Bootstrap 4 and Font Awesome 4 with starter templates
Flask-SQLAlchemy with basic User model
Easy database migrations with Flask-Migrate
Configuration in environment variables, as per The Twelve-Factor App
Flask-WTForms with login and registration forms
Flask-Login for authentication
Flask-Bcrypt for password hashing
Procfile for deploying to a PaaS (e.g. Heroku)
pytest and Factory-Boy for testing (example tests included)
Flask's Click CLI configured with simple commands
CSS and JS minification using webpack
npm support for frontend package management
Caching using Flask-Cache
Useful debug toolbar
Utilizes best practices: Blueprints and Application Factory patterns

Screenshots

Home page

Inspiration

Changelog

Unreleased

Update all node dependencies to latest versions
Switch to using Github Actions for template CI
Remove support for Node 10 as a Cookiecutter option
Refactored Docker image to use multistage builds more efficiently
Projects generated with the template use Github actions for CI
Upgrade Webpack to 5.x
Dropped Python 3.6 support
Added Python 3.9 and Python 3.10 support
Added Node 16 LTS

18.0.0 (09/09/2018)

Use CalVer (YY.MINOR.MICRO).
Upgrade to Bootstrap 4. Thanks @adawalli and @Hiyorim.
Use environment variables for configuration.
Add support for Pipenv.
Upgrade Python and Node dependencies.

0.13.0 (06/25/2017)

Use webpack for building front-end assets. Front-end dependencies are installed with NPM. Remove Flask-Assets and bower.json. Thanks @wroberts.

0.12.0 (11/06/2016)

Update Python dependencies.

0.11.1 (11/06/2016)

Correctly pass first parameter to Flask according to the 0.11 docs. Thanks @aliavni.
Remove setuptools and wheel as dependencies to fix deployment on Heroku. Thanks @Cabalist.
Make User.password a Binary field for compatibility with new versions of bcrypt. Thanks again @Cabalist.

0.11.0 (09/10/2016)

Use the FLASK_DEBUG system environment variable, instead of MYFLASKAPP_ENV, to control different configs for development and production environments

0.10.1 (08/28/2016)

Fix invoke test command.

0.10.0 (08/28/2016)

Update to Flask 0.11.
Use Click instead of Flask-Script for CLI commands.

0.9.0 (03/06/2016)

Update stale requirements.
Add CSRF protection.
Run lint command on Travis builds.
Test against Python 3.5.

0.8.0 (11/09/2015)

Update stale requirements.
Add lint, clean, and urls management commands.
Add isort.

Thanks @andreoliw for these contributions.

0.7.0 (04/14/2015)

Update extension import style to flask_* as per mitsuhiko/flask#1135.
Update stale requirements (Werkzeug, Flask-WTF, WTForms, Flask-Bcrypt, Flask-DebugToolbar, Flask-Migrate, Bootstrap, jQuery). Thanks @bsmithgall for notifying me of the critical patch to Flask-Migrate.

0.6.0 (12/01/2014)

Test the cookiecutter on Travis. Thanks @joshfriend.
Update stale requirements (Flask-WTF, Flask-Migrate, Flask-DebugToolbar)

0.5.0 (09/29/2014)

Fix .travis.yml.
Update stale requirements (Flask-WTF, WTForms, Flask-SQLAlchemy, jquery, Bootstrap)

0.4.3 (07/27/2014)

Add BaseFactory class.
Add compat.py module.
Tests pass on Python 3.

0.4.2 (07/27/2014)

Update factories to factory-boy >= 2.4.0 syntax.
Update stale requirements.

0.4.1 (06/07/2014)

Update stale requirements (Werkzeug 0.9.6, WTForms 2.0)
Fix unmatched div tag in home.html (thanks @level09)

0.4.0 (04/19/2014)

Add ReferenceCol for less verbose foreign key columns.
Add SurrogatePK mixin for adding integer primary key to a model.
Add base Model class that has CRUD convenience methods.
Fix setting BCrypt encryption complexity. Tests are much faster.
Add Role model to show ReferenceCol usage.
Switch to pytest.
Upgrade all out-of-date requirements.
More test examples.
Remove "year" from cookiecutter.json (just change LICENSE if necessary).

0.3.2 (02/26/2014)

Fix static assets.

0.3.1 (02/20/2014)

Update default year in cookiecutter.json. Thanks @Omeryl
Correct testing of redirects in webtests. Thanks @Widdershin
Fix POST action in nav form. Thanks @Widdershin.
Update Bootstrap (3.1.1) and jQuery (2.1.0)
Optional support for bower.
Minified assets aren't used in dev environment.

0.3.0 (12/08/2013)

More modular organization: each blueprint contains its own view, models, and forms in a directory. There is still a single directory for templates and static assets.
Use Flask-Bcrypt for password hashing.
Flask-Login for authentication.
Simple test setup. Just create a subclass of DbTestCase.
Flask-Testing support.
Use Factory-Boy for test factories.
Use WebTest for functional testing.
Add Flask-Debugtoolbar.
Migrations using Flask-Migrate.
Caching using Flask-Cache.
Add error page templates (404, 401, 500)
Add Font Awesome 4.0.3 for icons.

0.2.0 (09/21/2013)

Add manage.py script
Add Flask-Assets for CSS and JS bundling+minification
Use different configs for development and production environments, controlled by the MYFLASKAPP_ENV system environment variable
Use Blueprints and application factory pattern. The simple branch does not use these.

0.1.0 (08/20/2013)

First iteration
Bootstrap 3 final
Working User model and registration

Download Details:
Author: cookiecutter-flask
Source Code: https://github.com/cookiecutter-flask/cookiecutter-flask
License: MIT License

#flask #python #webpack

What is GEEK

Buddha Community

Cookiecutter-flask: A Flask Template for Cookiecutter

Steve Kunde

1592723950

Download a Flask template ready to plug in your business logic

Let’s assume after lots of hard work you have your machine learning model running the way it should. This model could be one which responds to a user’s request to classify a tweet sentiment or identify objects in an image or recommend a product or some other algorithm unique to your needs. You would now like to quickly deploy this model. The article below is an explanation of the template that I have created to get you up and running quickly.

#flask-framework #flask-python-appengine #flask-sqlalchemy #marshmallow #flask #programming

Flask Framework

1622195383

How Jinja2 templates work: Python and flask web development part 5

After receiving data from the user, we may either want to display it back to the user or store it in the database for later usage after processing it with our Python code. What we have at hand is python code data that the HTML has no business or no way coded to handle. These are two different worlds, the front end, and backend respectively. We need a way to call and interpolate these python objects into the Html template for the user to derive some business meaning out of it. We need a Jinja2 templating engine for that job. Yes, we could eliminate Jinja2 by turning our flask app to an API and having the front end handled by AJAX technologies or any front end frameworks like React, Vue, Angular, etc. In this post, we will be looking at how Jinja2 works and how best to use it in our flask applications.

In this tutorial we are going to look at how the jinja templating engine works. We will look at how it handles variable or python objects interpolation, conditional logic and finally template inheritance.

What is a template
What is jinja and its features
Jinja and its syntax
Template inheritance
Conclusion

Flask is a back end web development framework that depends on python. Technically we can’t have any backend code presented in the frontend html structures without the use of some interpolation techniques or technology. Jinja2 is that technique** or interpolation technology** developed in python.

#flask #web developemnt #flask #handling user requests #jinja2 templates #web development

Nico Jonsson

1605576444

How to Use DOM Manipulation properly in Angular

If you are coming from the background of working with angularjs, it was quite straight forward to access and manipulate the DOM there. You had access to the DOM node through element injected in the link function of the directive.

function link(scope, element, attrs) {
}

Or through angular.element which was an AngularJS’s built in subset of jQuery. But this approach had its drawbacks. It made your code tightly coupled with Browser’s API.

The new Angular (2 onwards) works on multiple platforms: mobile, web workers etc. So, they have introduced a number of APIs to work as an abstraction layer between your code and platform APIs. These APIs come in the form of different reference types likeElementRef, TemplateRef, ViewRef, ComponentRef and ViewContainerRef.

In this blog, we will see some examples of how these reference types can be used to manipulate DOM in angular. But before that let’s look at the ways to access these reference types within a Component/Directive.

DOM Queries

Angular has provided two ways to query/access various reference types within a Component/Directive. These are

ViewChild/ViewChildren
ContentChild/ContentChildren

ViewChild/ViewChildren

These are decorators which can be used within a Component/Directive as @ViewChild (returns a single reference) or @ViewChildren (returns a list of references in the form of a QueryList). These will assign the values of reference types from template to the component fields they are applied to. The basic usage is as follow:

@ViewChild(selector, {read: ReferenceType}) fieldName;

A selector can be a string representing a template reference variable, or a Component/Directive class, or a TemplateRef or a provider defined in the child component tree.

@ViewChild("myElem") template: ElementRef;

The second parameter is optional and is only required to query some reference types which can’t be inferred easily by Angular like ViewContainerRef.

@ViewChild("myContainer", {read: ViewContainerRef}) container: ViewContainerRef;

ContentChild/ContentChildren

The usage is pretty much similar to that of ViewChild/ViewChildren. The only difference is that it queries within the <ng-content> projected elements of the component while the @ViewChild queries within the template of the component. This will be explained better in the examples of upcoming sections.

DOM access via ElementRef

ElementRef is a very basic abstraction layer on a DOM element in Angular. It’s an angular wrapper around the native element.

You can get hold of ElementRef in a Component or Directive in following ways:

Dependency Injection

Host element of a Component or Directive can be accessed via direct DI in the constructor.

@Component({
  selector: 'app-test',
  template: '<div>I am a test component</div>'
})
export class TestComponent implements OnInit {

  constructor(private element: ElementRef) { }

  ngOnInit() {
    console.log(this.element.nativeElement);
  }

}
/*
* Output: 
*   <app-test>
*     <div>I am a test component</div>
*   </app-test>
* */

Using ViewChild and Template Reference Variables

@Component({
  selector: 'app-test',
  template: `
    <div #child1>First Child</div>
    <div>Second Child</div>
  `
})
export class TestComponent implements OnInit {

  @ViewChild("child1") firstChild: ElementRef;

  constructor() { }

  ngOnInit() {
    console.log(this.firstChild.nativeElement);
  }

}

/*
* Output: <div>First Child</div>
* */

Using ContentChild

Works in a similar manner as that of @ViewChild, but for <ng-content> projected elements.

// Child Component
@Component({
  selector: "component-a",
  template: `<ng-content></ng-content>`
})
export class ComponentA {
  @ContentChild("contentChild") contentChild: ElementRef;
  
  ngOnInit() {
    console.log(this.contentChild.nativeElement);
  }
}
// Parent Component
@Component({
  selector: 'app-test',
  template: `
    <component-a>
      <div #contentChild>Content Child 1</div>
      <div>Content Child 2</div>
    </component-a>
  `
})
export class TestComponent implements OnInit {}
/*
* Output: <div>Content Child 1</div>
* */

It looks pretty straight forward that you can easily access a DOM element via ElementRef and then manipulate the DOM by accessing the nativeElement. Something like this:

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body" #body>
    </div>
    <div class="footer">I am a footer</div>
  `
})
export class TestComponent implements AfterContentInit {
  @ViewChild("body") bodyElem: ElementRef;

  ngAfterContentInit(): void {
    this.bodyElem.nativeElement.innerHTML = `<div>Hi, I am child added by directly calling the native APIs.</div>`;
  }

}

However, the direct usage of ElementRef is discouraged by Angular Team because it directly provides the access to DOM which can make your application vulnerable to XSS attacks. It also creates tight coupling between your application and rendering layers which makes is difficult to run an app on multiple platforms.

Everything is a ‘View’ in Angular

A view is the smallest building block of an angular app’s UI. Every component has its own view. You can consider it as a group of elements which can be created and destroyed together.

A view can be classified into two types:

Embedded Views — created from templates
Host Views — created from components

Displaying a view in UI can be broken down into two steps:

Creating a view from template or component
Rendering a view into a view container

Embedded Views

Embedded views are created from templates defined using <ng-template> element.

Creating an embedded view

First a template needs to be accessed within a component as TemplateRefusing @ViewChild and template reference variable. Then, an embedded view can be created from a TemplateRef by passing a data-binding context.

const viewRef = this.template.createEmbeddedView({
  name: "View 1"
});

This context is being consumed by the template in<ng-template>.

<ng-template #template let-viewName="name">
  <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
</ng-template>

You can also use the $implicit property in the context if you have only a single property to bind.

const viewRef = this.template.createEmbeddedView({
  $implicit: "View 1"
});

In this case, you can skip assigning values to template variables.

<ng-template #template let-viewName>
  <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
</ng-template>

Rendering an embedded view

Till now, we have created only an instance of ViewRef. This view is still not visible in the UI. In order to see it in the UI, we need a placeholder (a view container) to render it. This placeholder is being provided by ViewContainerRef.

Any element can serve as a view container, however <ng-container> is a better candidate as it is rendered as a comment and doesn’t leave any redundant element in the html DOM.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container #container></ng-container>
    </div>
    <div class="footer">I am a footer</div>

    <ng-template #template let-viewName="name">
      <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
    </ng-template>
  `,
})
export class TestComponent implements AfterContentInit {

  @ViewChild("template") template: TemplateRef;
  @ViewChild("container", {read: ViewContainerRef}) container: ViewContainerRef;

  constructor() { }

  ngAfterContentInit(): void {
    const viewRef = this.template.createEmbeddedView({
      name: "View 1"
    });
    this.container.insert(viewRef);
  }
}

Both <ng-container> and <ng-template> elements will be rendered as comments leaving the html DOM neat and clean.

The above 2 steps process of creating a view and adding it into a container can further be reduced by using the createEmbeddedView method available in the ViewContainerRef itself.

this.container.createEmbeddedView(this.template, {
  name: "View 1"
});

This can be further simplified by moving the whole view creation logic from component class to the template using ngTemplateOutlet and ngTemplateOutletContext.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container [ngTemplateOutlet]="template" [ngTemplateOutletContext]="{name: 'View 1'}"></ng-container>
    </div>
    <div class="footer">I am a footer</div>

    <ng-template #template let-viewName="name">
      <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
    </ng-template>
  `
})
export class TestComponent {}

Host Views

Host Views are quite similar to Embedded View. The only difference is that the Host Views are created from components instead of templates.

Creating a host view

In order to create a host view, first you need to create a ComponentFactory of the component you want to render using ComponentFactoryResolver.

constructor(
  private componentFactoryResolver: ComponentFactoryResolver
) {
  this.someComponentFactory = this.componentFactoryResolver.resolveComponentFactory(SomeComponent);
}

Then, a dynamic instance of the component is created by passing an Injector instance to the factory. Every component should be bound to an instance of Injector. You can use the injector of the parent component for the dynamically created components.

const componentRef = this.someComponentFactory.create(this.injector);
const viewRef = componentRef.hostView;

Rendering a host view

Rendering a host view is almost similar to rendering an embedded view. You can directly insert it into a view container.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container #container></ng-container>
    </div>
    <div class="footer">I am a footer</div>
  `,
})
export class TestComponentComponent implements AfterContentInit {

  @ViewChild("container", {read: ViewContainerRef}) container: ViewContainerRef;

  private someComponentFactory: ComponentFactory<SomeComponent>;

  constructor(
    private componentFactoryResolver: ComponentFactoryResolver,
    private injector: Injector
  ) {
    this.someComponentFactory = this.componentFactoryResolver.resolveComponentFactory(SomeComponent);
  }

  ngAfterContentInit(): void {
    const componentRef = this.someComponentFactory.create(this.injector);
    const viewRef = componentRef.hostView;
    this.container.insert(viewRef);
  }
}

Or by directly calling the createComponent method of ViewContainerRef and passing the component factory instance.

this.container.createComponent(this.someComponentFactory);

Now, similar to embedded view, we can also shift the whole logic of host view creation in template itself using ngComponentOutlet.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container [ngComponentOutlet]="comp"></ng-container>
    </div>
    <div class="footer">I am a footer</div>
  `
})
export class TestComponent {
  comp = SomeComponent;
}

Don’t forget to store the reference of the component class in parent component’s field. The template has access only to the fields of the components.

Summary

Here we come to an end. Let’s conclude what we have understood till now.

We can access the DOM in Angular using different reference types likeElementRef, TemplateRef, ViewRef, ComponentRef and ViewContainerRef.
These reference types can be queried from templates using @ViewChild and @ContentChild.
Browser’s native DOM element can be accessed via ElementRef. However, manipulating this element directly is discouraged because of security reasons.
Concept of Views.
How to create and render an Embedded View.
How to create and render a Component View.

So, that’s it for today about understanding DOM manipulation in Angular.

Originally published by medium

Ruth Gleason

1647201600