text:
import React, {Component} from 'react';
import {connect} from 'react-redux';

import {getUserStories, editUserStory, deleteUserStory} from '../../actions/UserStory';
import {showFloatingMessage, MESSAGE_CLASSES} from '../../actions/LocalActions';
import {addUserStoryToSprint, getSprints} from '../../actions/Sprint';
import Input, {TYPES} from '../../atoms/Input';
import TaskList from '../TaskList';
import TaskCreation from '../TaskCreation';

import './UserStoryList.less';

class UserStoryList extends Component {
    static contextTypes = {
        router: React.PropTypes.object.isRequired
    };

    static propTypes = {
        projectID: React.PropTypes.string.isRequired,
        loadedUserStories: React.PropTypes.object.isRequired,
        getUserStories: React.PropTypes.func.isRequired,
        showFloatingMessage: React.PropTypes.func.isRequired,
        editUserStory: React.PropTypes.func.isRequired,
        editedUserStory: React.PropTypes.object.isRequired,
        deleteUserStory: React.PropTypes.func.isRequired,
        deletedUserStory: React.PropTypes.object.isRequired
    };

    constructor(props) {
        super(props);

        this.state = {
            userStories: [],
            editCard: -1,
            name: '',
            description: '',
            priority: 0,
            effort: -1,
            userStoryForTask: -1,
            taskCreation: false,
            menu: undefined
        };

        if (this.props.projectID) {
            this.props.getUserStories(this.props.projectID);
            this.props.getSprints();
        }
    }

    componentWillReceiveProps(newProps) {
        if (newProps.loadedUserStories.loaded && !newProps.loadedUserStories.error) {
            this.setState({
                userStories: newProps.loadedUserStories.data
            });
        } else if (newProps.loadedUserStories.error) {
            this.props.showFloatingMessage({
                message: newProps.loadedUserStories.errorMessage,
                messageClass: MESSAGE_CLASSES.ERROR
            });
        } else {
            this.setState({
                userStories: []
            });
        }

        if (newProps.editedUserStory.loaded && newProps.editedUserStory.error) {
            this.props.showFloatingMessage({
                message: newProps.editedUserStory.errorMessage,
                messageClass: MESSAGE_CLASSES.ERROR
            });
        }

        if (newProps.deletedUserStory.loaded && newProps.deletedUserStory.error) {
            this.props.showFloatingMessage({
                message: newProps.deletedUserStory.errorMessage,
                messageClass: MESSAGE_CLASSES.ERROR
            });
        }

        if (newProps.addedUserStoryToSprint.loaded && newProps.addedUserStoryToSprint.error) {
            this.props.showFloatingMessage({
                message: newProps.addedUserStoryToSprint.errorMessage,
                messageClass: MESSAGE_CLASSES.ERROR
            });
        }

        this.props = newProps;
    }

    static getShortDescription(description) {
        return description.length > 140 ?
        description.substring(0, 140) + '...' :
            description;
    }

    static getEffortStringFor(effort) {
        switch (effort) {
            case 1:
                return 'Very easy (1)';
            case 2:
                return 'Easy (2)';
            case 3:
                return 'Normal (3)';
            case 5:
                return 'Hard (5)';
            case 8:
                return 'Very hard (8)';
            default :
                return 'Not found (?)';
        }
    }

    static getPriorityStringFor(priority) {
        switch (priority) {
            case 0:
                return 'Option';
            case 1:
                return 'Desired';
            case 2:
                return 'Required';
            default :
                return 'Not found';
        }
    }

    handleChange(e, field) {
        let nextState = {};

        nextState[field] = e.target.value;

        this.setState(nextState);
    }

    switchEdit(e, number) {
        this.setState({
            editCard: number,
            name: e.name,
            description: e.description,
            effort: e.effort,
            priority: e.priority
        });
    }

    showTaskCreation(userStory) {
        this.setState({
            userStoryForTask: userStory,
            taskCreation: true
        });
    }

    acceptEdit(number) {
        if (!this.state.name || this.state.name.length === 0) {
            this.props.showFloatingMessage({
                message: 'Name needed',
                messageClass: MESSAGE_CLASSES.ERROR
            });
        } else {
            let userStory = this.state.userStories[number];

            userStory.name = this.state.name;
            userStory.description = this.state.description;
            userStory.effort = parseInt(this.state.effort);
            userStory.priority = parseInt(this.state.priority);

            this.setState({
                editCard: -1
            }, () => this.props.editUserStory(userStory));
        }
    }

    remove(number) {
        let userStory = this.state.userStories[number];

        let newUserStories = this.state.userStories.splice(number, 1);

        this.setState({
            userStories: newUserStories
        }, () => this.props.deleteUserStory(userStory));
    }

    getEditViewForUserStory(e, i) {
        return (

                     this.switchEdit({}, -1)}>
                     this.acceptEdit(i)}>

                    <Input
                        className="user-story-title user-story-input-name"
                        type={TYPES.TEXT}
                        value={this.state.name}
                        onChange={(e) => this.handleChange(e, 'name')}
                        name="name"
                        placeholder="Name"
                    />

                        <Input
                            type={TYPES.TEXTAREA}
                            className="user-story-input-description"
                            rows={4}
                            name="description"
                            value={this.state.description}
                            onChange={(e) => this.handleChange(e, 'description')}
                            placeholder="Description"/>

                        US Number : {e.number} -
                        Effort :
                        <Input
                            type={TYPES.SELECT}
                            name="effort"
                            value={this.state.effort}
                            onChange={(e) => this.handleChange(e, 'effort')}
                            options={[
                                {name: 'Very Easy (1)', value: '1'},
                                {name: 'Easy (2)', value: '2'},
                                {name: 'Normal (3)', value: '3'},
                                {name: 'Hard (5)', value: '5'},
                                {name: 'Very Hard (8)', value: '8'}
                            ]}/>
                         - Priority :
                        <Input
                            type={TYPES.SELECT}
                            name="priority"
                            value={this.state.priority}
                            onChange={(e) => this.handleChange(e, 'priority')}
                            options={[
                                {name: 'Option', value: '1'},
                                {name: 'Desired', value: '2'},
                                {name: 'Required', value: '3'}
                            ]}/>

        );
    }

    showSprintMenu(userStory, e) {
        if (this.state.menu) {
            return this.setState({
                menu: undefined
            });
        }

        let elementRect =
            e.target.getBoundingClientRect();

        console.log(this.props.loadedSprints.data);

        let menu = (

                    Add to

                {this.props.loadedSprints.data.map((sprint, i) =>

 {
                             console.log({
                                 _id: sprint._id,
                                 userStoryID: userStory._id
                             });
                             this.setState({menu: undefined},
                                 () => this.props.addUserStoryToSprint(
                                     {
                                         _id: sprint._id,
                                         userStoryID: userStory._id
                                     }
                                 ));
                         }}>
                        {sprint.name}

                )}

        );

        this.setState({
            menu: menu
        });
    }

    getClassicViewForUserStory(e, i, editButtonVisible) {
        let containerEditButton = undefined;

        if (editButtonVisible) {
            containerEditButton = (

                     this.showTaskCreation(e)}>
                     this.showSprintMenu(e, el)}>
                     this.remove(i)}>
                     this.switchEdit(e, i)}>

            );
        }

        return (

                {containerEditButton}

                    {e.name}

                        {UserStoryList.getShortDescription(e.description)}

                    <TaskList tasks={e.tasks}
                              userStoryID={e._id}
                              refreshUserStories={
                                  () => this.props.getUserStories(this.props.projectID)}
                    />

                        US Number : {e.number} -
                        Effort : {UserStoryList.getEffortStringFor(e.effort)} -
                        Priority : {UserStoryList.getPriorityStringFor(e.priority)}

        );
    }

    getViewForUserStory(e, i) {
        const {editCard} = this.state;

        let userStory = undefined;

        if (editCard === -1) {
            userStory = this.getClassicViewForUserStory(e, i, true);
        } else if (editCard === i) {
            userStory = this.getEditViewForUserStory(e, i);
        } else {
            userStory = this.getClassicViewForUserStory(e, i, false);
        }

        return (

                {userStory}

        );
    }

    render() {
        const {userStories, taskCreation, menu} = this.state;

        return (

                {userStories.sort((e1, e2) => e1.priority > e2.priority ? -1 : 0)
                    .map((e, i) => this.getViewForUserStory(e, i))}
                {taskCreation && <TaskCreation
                    userStoryID={this.state.userStoryForTask._id}
                    dismiss={() => this.setState({
                        userStoryForTask: null,
                        taskCreation: false
                    }, () => this.props.getUserStories(this.props.projectID))}
                />
                }
                {menu}

        );
    }
}

function mapStateToProps(state) {
    return {
        loadedUserStories: state.loadedUserStories,
        editedUserStory: state.editedUserStory,
        deletedUserStory: state.deletedUserStory,
        loadedSprints: state.loadedSprints,
        addedUserStoryToSprint: state.addedUserStoryToSprint
    };
}

function mapDispatchToProps(dispatch) {
    return {
        getUserStories: (id) =>
            dispatch(getUserStories(id)),
        showFloatingMessage: (params) =>
            dispatch(showFloatingMessage(params)),
        editUserStory: (params) =>
            dispatch(editUserStory(params)),
        deleteUserStory: (params) =>
            dispatch(deleteUserStory(params)),
        addUserStoryToSprint: (params) =>
            dispatch(addUserStoryToSprint(params)),
        getSprints: () =>
            dispatch(getSprints())
    };
}

export default connect(mapStateToProps, mapDispatchToProps)(UserStoryList);


text:
module Reddit.Routes.Moderation where

import Reddit.Types.Message
import Reddit.Types.Moderation
import Reddit.Types.Options
import Reddit.Types.Subreddit
import Reddit.Types.User

import Network.API.Builder.Routes

bansListing :: Options BanID -> SubredditName -> Route
bansListing opts (R sub) =
  Route [ "r", sub, "about", "banned" ]
        [ "before" =. before opts
        , "after" =. after opts
        , "limit" =. limit opts]
        "GET"

banLookup :: Username -> SubredditName -> Route
banLookup (Username u) (R sub) =
  Route [ "r", sub, "about", "banned" ]
        [ "user" =. u ]
        "GET"

modmail :: Options MessageID -> Route
modmail opts =
  Route [ "message", "moderator" ]
        [ "before" =. before opts
        , "after" =. after opts
        , "limit" =. limit opts ]
        "GET"

redpajama_set_name: RedPajamaGithub


text:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<TITLE>
Overview (DataFu Hourglass)
</TITLE>

<META NAME="date" CONTENT="2013-12-12">

<LINK REL ="stylesheet" TYPE="text/css" HREF="stylesheet.css" TITLE="Style">

    Overview
      Package
      Class
      Use
      Tree
      Deprecated
      Index
      Help

 PREV
 NEXT

  FRAMES
 NO FRAMES

  All Classes

DataFu Hourglass

A framework for incrementally processing data in Hadoop.

See:

          Description

Packages

datafu.hourglass.avro
Input and output formats for using Avro in incremental Hadoop jobs.

datafu.hourglass.fs
Classes for working with the file system.

datafu.hourglass.jobs
Incremental Hadoop jobs and some supporting classes.

datafu.hourglass.mapreduce
Implementations of mappers, combiners, and reducers used by incremental jobs.

datafu.hourglass.model
Interfaces which define the incremental processing model.

datafu.hourglass.schemas
Classes that help manage the Avro schemas used by the jobs.

A framework for incrementally processing data in Hadoop.

    Overview
      Package
      Class
      Use
      Tree
      Deprecated
      Index
      Help

 PREV
 NEXT

  FRAMES
 NO FRAMES

  All Classes

Matthew Hayes


text:
package com.i906.mpt.prayer;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.i906.mpt.api.prayer.EmptyPrayerData;
import com.i906.mpt.api.prayer.PrayerData;
import com.i906.mpt.api.prayer.PrayerDataTypeAdapter;
import com.i906.mpt.api.prayer.PrayerProviderException;
import com.i906.mpt.date.DateTimeHelper;
import com.i906.mpt.prefs.InterfacePreferences;

import org.junit.Before;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExpectedException;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;

import java.io.InputStream;
import java.io.InputStreamReader;
import java.util.Calendar;
import java.util.List;

import static org.assertj.core.api.Assertions.assertThat;
import static org.mockito.Mockito.when;

/**
 * @author Noorzaini Ilhami
 */
public class PrayerContextTest {

    @Rule
    public final ExpectedException mExpectedException = ExpectedException.none();

    @Mock
    private DateTimeHelper mDateHelper;

    @Mock
    private InterfacePreferences mPreferences;

    private PrayerContext mPrayerContext;
    private PrayerContext mPrayerContextWithoutNextData;

    @Before
    public void setup() {
        MockitoAnnotations.initMocks(this);
        InputStream in6 = this.getClass().getClassLoader().getResourceAsStream("prayer-6.json");
        InputStream in7 = this.getClass().getClassLoader().getResourceAsStream("prayer-7.json");

        Gson gson = new GsonBuilder()
                .registerTypeAdapter(PrayerData.class, new PrayerDataTypeAdapter())
                .create();

        PrayerData p6 = gson.fromJson(new InputStreamReader(in6), PrayerData.class);
        PrayerData p7 = gson.fromJson(new InputStreamReader(in7), PrayerData.class);

        mPrayerContext = new PrayerContextImpl(mDateHelper, mPreferences, p6, p7);
        mPrayerContextWithoutNextData = new PrayerContextImpl(mDateHelper, mPreferences, p6, new EmptyPrayerData("JAKIM"));
    }

    @Test
    public void getCurrentPrayer() {
        Calendar n = Calendar.getInstance();
        n.set(2016, 5, 3, 14, 0, 0);

        Calendar c = Calendar.getInstance();

        when(mDateHelper.getCurrentDate())
                .thenReturn(3);

        when(mDateHelper.getNow())
                .thenReturn(n);

        when(mDateHelper.getCalendarInstance())
                .thenReturn(c);

        Prayer prayer = mPrayerContext.getCurrentPrayer();
        assertThat(prayer.getIndex()).isEqualTo(Prayer.PRAYER_ZOHOR);
        assertThat(prayer.getDate()).hasTime(1464930840000L);

        Prayer prayer2 = mPrayerContextWithoutNextData.getCurrentPrayer();
        assertThat(prayer2.getIndex()).isEqualTo(Prayer.PRAYER_ZOHOR);
        assertThat(prayer2.getDate()).hasTime(1464930840000L);
    }

    @Test
    public void getNextPrayerSameDay() {
        Calendar n = Calendar.getInstance();
        n.set(2016, 5, 3, 14, 0, 0);

        Calendar c = Calendar.getInstance();

        when(mDateHelper.getCurrentDate())
                .thenReturn(3);

        when(mDateHelper.getNextDate())
                .thenReturn(4);

        when(mDateHelper.isTommorowNewMonth())
                .thenReturn(false);

        when(mDateHelper.getNow())
                .thenReturn(n);

        when(mDateHelper.getCalendarInstance())
                .thenReturn(c);

        Prayer prayer = mPrayerContext.getNextPrayer();
        assertThat(prayer.getIndex()).isEqualTo(Prayer.PRAYER_ASAR);
        assertThat(prayer.getDate()).hasTime(1464943140000L);

        Prayer prayer2 = mPrayerContextWithoutNextData.getNextPrayer();
        assertThat(prayer2.getIndex()).isEqualTo(Prayer.PRAYER_ASAR);
        assertThat(prayer2.getDate()).hasTime(1464943140000L);
    }

    @Test
    public void getNextPrayerDifferentDay() {
        Calendar n = Calendar.getInstance();
        n.set(2016, 5, 3, 21, 0, 0);

        Calendar c = Calendar.getInstance();

        when(mDateHelper.getCurrentDate())
                .thenReturn(3);

        when(mDateHelper.getNextDate())
                .thenReturn(4);

        when(mDateHelper.isTommorowNewMonth())
                .thenReturn(false);

        when(mDateHelper.getNow())
                .thenReturn(n);

        when(mDateHelper.getCalendarInstance())
                .thenReturn(c);

        Prayer prayer = mPrayerContext.getNextPrayer();
        assertThat(prayer.getIndex()).isEqualTo(Prayer.PRAYER_IMSAK);
        assertThat(prayer.getDate()).hasTime(1464989400000L);

        Prayer prayer2 = mPrayerContextWithoutNextData.getNextPrayer();
        assertThat(prayer2.getIndex()).isEqualTo(Prayer.PRAYER_IMSAK);
        assertThat(prayer2.getDate()).hasTime(1464989400000L);
    }

    @Test
    public void getNextPrayerDifferentMonth() {
        Calendar n = Calendar.getInstance();
        n.set(2016, 5, 30, 21, 0, 0);

        Calendar c = Calendar.getInstance();

        when(mDateHelper.getCurrentDate())
                .thenReturn(30);

        when(mDateHelper.getNextDate())
                .thenReturn(1);

        when(mDateHelper.isTommorowNewMonth())
                .thenReturn(true);

        when(mDateHelper.getNow())
                .thenReturn(n);

        when(mDateHelper.getCalendarInstance())
                .thenReturn(c);

        Prayer prayer = mPrayerContext.getNextPrayer();
        assertThat(prayer.getIndex()).isEqualTo(Prayer.PRAYER_IMSAK);
        assertThat(prayer.getDate()).hasTime(1467322440000L);

        mExpectedException.expect(PrayerProviderException.class);
        mPrayerContextWithoutNextData.getNextPrayer();
    }

    @Test
    public void getCurrentPrayerList() {
        when(mDateHelper.getCurrentDate())
                .thenReturn(30);

        List<Prayer> list = mPrayerContext.getCurrentPrayerList();

        Prayer p = null;
        for (int i = 0; i < 8; i++) {
            Prayer c = list.get(i);

            assertThat(c.getIndex()).isEqualTo(i);
            assertThat(c.getDate()).isInSameDayAs("2016-06-30");

            if (p != null) {
                assertThat(c.getDate()).isAfter(p.getDate());
            }

            p = c;
        }
    }

    @Test
    public void getNextPrayerListSameMonth() {
        when(mDateHelper.getCurrentDate())
                .thenReturn(3);

        when(mDateHelper.getNextDate())
                .thenReturn(4);

        when(mDateHelper.isTommorowNewMonth())
                .thenReturn(false);

        List<Prayer> list = mPrayerContext.getNextPrayerList();

        Prayer p = null;
        for (int i = 0; i < 8; i++) {
            Prayer c = list.get(i);

            assertThat(c.getIndex()).isEqualTo(i);
            assertThat(c.getDate()).isInSameDayAs("2016-06-04");

            if (p != null) {
                assertThat(c.getDate()).isAfter(p.getDate());
            }

            p = c;
        }
    }

    @Test
    public void getNextPrayerListDifferentMonth() {
        when(mDateHelper.getCurrentDate())
                .thenReturn(30);

        when(mDateHelper.getNextDate())
                .thenReturn(1);

        when(mDateHelper.isTommorowNewMonth())
                .thenReturn(true);

        List<Prayer> list = mPrayerContext.getNextPrayerList();

        Prayer p = null;
        for (int i = 0; i < 8; i++) {
            Prayer c = list.get(i);

            assertThat(c.getIndex()).isEqualTo(i);
            assertThat(c.getDate()).isInSameDayAs("2016-07-01");

            if (p != null) {
                assertThat(c.getDate()).isAfter(p.getDate());
            }

            p = c;
        }
    }
}


text:
{% extends 'base.html' %}

{% load media %}

{% block title_text %}Вход{% endblock %}
{% block css %}{% include_media 'radio.css' %}{% endblock %}

{% block js %}

{% endblock %}

{% block body %}

{% endblock %}


text:
@title
Style Guide

@intro
Write Angular with style.

@description

Looking for an opinionated guide to Angular syntax, conventions, and application structure?
Step right in!
This style guide presents preferred conventions and, as importantly, explains why.

{@a toc}

# Contents

  * [Single responsibility](guide/styleguide#single-responsibility)
  * [Naming](guide/styleguide#naming)
  * [Coding conventions](guide/styleguide#coding-conventions)
  * [App structure and Angular modules](guide/styleguide#application-structure-and-angular-modules)
  * [Components](guide/styleguide#components)
  * [Directives](guide/styleguide#directives)
  * [Services](guide/styleguide#services)
  * [Data services](guide/styleguide#data-services)
  * [Lifecycle hooks](guide/styleguide#lifecycle-hooks)
  * [Appendix](guide/styleguide#appendix)

## Style vocabulary

Each guideline describes either a good or bad practice, and all have a consistent presentation.

The wording of each guideline indicates how strong the recommendation is.

**Do** is one that should always be followed.
_Always_ might be a bit too strong of a word.
Guidelines that literally should always be followed are extremely rare.
On the other hand, you need a really unusual case for breaking a *Do* guideline.

**Consider** guidelines should generally be followed.
If you fully understand the meaning behind the guideline and have a good reason to deviate, then do so. Please strive to be consistent.

**Avoid** indicates something you should almost never do. Code examples to *avoid* have an unmistakeable red header.

**Why?** gives reasons for following the previous recommendations.

## File structure conventions

Some code examples display a file that has one or more similarly named companion files.
For example, `hero.component.ts` and `hero.component.html`.

The guideline uses the shortcut `hero.component.ts|html|css|spec` to represent those various files. Using this shortcut makes this guide's file structures easier to read and more terse.

{@a single-responsibility}

## Single responsibility

Apply the
single responsibility principle (SRP)
to all components, services, and other symbols.
This helps make the app cleaner, easier to read and maintain, and more testable.

### {@a 01-01}Rule of One

#### Style 01-01

**Do** define one thing, such as a service or component, per file.

**Consider** limiting files to 400 lines of code.

**Why?** One component per file makes it far easier to read, maintain, and avoid
collisions with teams in source control.

**Why?** One component per file avoids hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures, or unwanted coupling with dependencies.

**Why?** A single component can be the default export for its file which facilitates lazy loading with the router.

The key is to make the code more reusable, easier to read, and less mistake prone.

The following *negative* example defines the `AppComponent`, bootstraps the app,
defines the `Hero` model object, and loads heroes from the server all in the same file.
*Don't do this*.

It is a better practice to redistribute the component and its
supporting classes into their own, dedicated files.

As the app grows, this rule becomes even more important.
Back to top

### {@a 01-02}Small functions

#### Style 01-02

**Do** define small functions

**Consider** limiting to no more than 75 lines.

**Why?** Small functions are easier to test, especially when they do one thing and serve one purpose.

**Why?** Small functions promote reuse.

**Why?** Small functions are easier to read.

**Why?** Small functions are easier to maintain.

**Why?** Small functions help avoid hidden bugs that come with large functions that share variables with external scope, create unwanted closures, or unwanted coupling with dependencies.

Back to top

## Naming

Naming conventions are hugely important to maintainability and readability. This guide recommends naming conventions for the file name and the symbol name.

### {@a 02-01}General Naming Guidelines

#### Style 02-01

**Do** use consistent names for all symbols.

**Do** follow a pattern that describes the symbol's feature then its type. The recommended pattern is `feature.type.ts`.

**Why?** Naming conventions help provide a consistent way to find content at a glance. Consistency within the project is vital. Consistency with a team is important. Consistency across a company provides tremendous efficiency.

**Why?** The naming conventions should simply help find desired code faster and make it easier to understand.

**Why?** Names of folders and files should clearly convey their intent. For example, `app/heroes/hero-list.component.ts` may contain a component that manages a list of heroes.

Back to top

### {@a 02-02}Separate file names with dots and dashes

#### Style 02-02

**Do** use dashes to separate words in the descriptive name.

**Do** use dots to separate the descriptive name from the type.

**Do** use consistent type names for all components following a pattern that describes the component's feature then its type. A recommended pattern is `feature.type.ts`.

**Do** use conventional type names including `.service`, `.component`, `.pipe`, `.module`, and `.directive`.
Invent additional type names if you must but take care not to create too many.

**Why?** Type names provide a consistent way to quickly identify what is in the file.

**Why?** Type names make it easy to find a specific file type using an editor or IDE's fuzzy search techniques.

**Why?** Unabbreviated type names such as `.service` are descriptive and unambiguous.
Abbreviations such as `.srv`, `.svc`, and `.serv` can be confusing.

**Why?** Type names provide pattern matching for any automated tasks.

Back to top

### {@a 02-03}Symbols and file names

#### Style 02-03

**Do** use consistent names for all assets named after what they represent.

**Do** use upper camel case for class names.

**Do** match the name of the symbol to the name of the file.

**Do** append the symbol name with the conventional suffix (such as `Component`,
`Directive`, `Module`, `Pipe`, or `Service`) for a thing of that type.

**Do** give the filename the conventional suffix (such as `.component.ts`, `.directive.ts`,
`.module.ts`, `.pipe.ts`, or `.service.ts`) for a file of that type.

**Why?** Consistent conventions make it easy to quickly identify
and reference assets of different types.

  <col width="50%">

  </col>

  <col width="50%">

  </col>

      Symbol Name

      File Name

        @Component({ ... })
        export class AppComponent { }

      app.component.ts

        @Component({ ... })
        export class HeroesComponent { }

      heroes.component.ts

        @Component({ ... })
        export class HeroListComponent { }

      hero-list.component.ts

        @Component({ ... })
        export class HeroDetailComponent { }

      hero-detail.component.ts

        @Directive({ ... })
        export class ValidationDirective { }

      validation.directive.ts

        @NgModule({ ... })
        export class AppModule

      app.module.ts

        @Pipe({ name: 'initCaps' })
        export class InitCapsPipe implements PipeTransform { }

      init-caps.pipe.ts

        @Injectable()
        export class UserProfileService { }

      user-profile.service.ts

Back to top

### {@a 02-04}Service names

#### Style 02-04

**Do** use consistent names for all services named after their feature.

**Do** suffix a service class name with `Service`.
For example, something that gets data or heroes
should be called a `DataService` or a `HeroService`.

A few terms are unambiguously services. They typically
indicate agency by ending in "-er". You may prefer to name
a service that logs messages `Logger` rather than `LoggerService`.
Decide if this exception is agreeable in your project.
As always, strive for consistency.

**Why?** Provides a consistent way to quickly identify and reference services.

**Why?** Clear service names such as `Logger` do not require a suffix.

**Why?** Service names such as `Credit` are nouns and require a suffix and should be named with a suffix when it is not obvious if it is a service or something else.

  <col width="50%">

  </col>

  <col width="50%">

  </col>

      Symbol Name

      File Name

        @Injectable()
        export class HeroDataService { }

      hero-data.service.ts

        @Injectable()
        export class CreditService { }

      credit.service.ts

        @Injectable()
        export class Logger { }

      logger.service.ts

Back to top

### {@a 02-05}Bootstrapping

#### Style 02-05

**Do** put bootstrapping and platform logic for the app in a file named `main.ts`.

**Do** include error handling in the bootstrapping logic.

**Avoid** putting app logic in `main.ts`. Instead, consider placing it in a component or service.

**Why?** Follows a consistent convention for the startup logic of an app.

**Why?** Follows a familiar convention from other technology platforms.

Back to top

### {@a 02-06}Directive selectors

#### Style 02-06

**Do** Use lower camel case for naming the selectors of directives.

**Why?** Keeps the names of the properties defined in the directives that are bound to the view consistent with the attribute names.

**Why?** The Angular HTML parser is case sensitive and recognizes lower camel case.

Back to top

### {@a 02-07}Custom prefix for components

#### Style 02-07

**Do** use a hyphenated, lowercase element selector value (e.g. `admin-users`).

**Do** use a custom prefix for a component selector.
For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the prefix `admin` represents an admin feature area.

**Do** use a prefix that identifies the feature area or the app itself.

**Why?** Prevents element name collisions with components in other apps and with native HTML elements.

**Why?** Makes it easier to promote and share the component in other apps.

**Why?** Components are easy to identify in the DOM.

### {@a 02-08}Custom prefix for directives

#### Style 02-08

**Do** use a custom prefix for the selector of directives (e.g, the prefix `toh` from **T**our **o**f **H**eroes).

**Do** spell non-element selectors in lower camel case unless the selector is meant to match a native HTML attribute.

**Why?** Prevents name collisions.

**Why?** Directives are easily identified.

Back to top

### {@a 02-09}Pipe names

#### Style 02-09

**Do** use consistent names for all pipes, named after their feature.

**Why?** Provides a consistent way to quickly identify and reference pipes.

  <col width="50%">

  </col>

  <col width="50%">

  </col>

      Symbol Name

      File Name

        @Pipe({ name: 'ellipsis' })
        export class EllipsisPipe implements PipeTransform { }

      ellipsis.pipe.ts

        @Pipe({ name: 'initCaps' })
        export class InitCapsPipe implements PipeTransform { }

      init-caps.pipe.ts

Back to top

### {@a 02-10}Unit test file names

#### Style 02-10

**Do** name test specification files the same as the component they test.

**Do** name test specification files with a suffix of `.spec`.

**Why?** Provides a consistent way to quickly identify tests.

**Why?** Provides pattern matching for [karma](http://karma-runner.github.io/) or other test runners.

  <col width="50%">

  </col>

  <col width="50%">

  </col>

      Symbol Name

      File Name

      Components

      heroes.component.spec.ts

      hero-list.component.spec.ts

      hero-detail.component.spec.ts

      Services

      logger.service.spec.ts

      hero.service.spec.ts

      filter-text.service.spec.ts

      Pipes

      ellipsis.pipe.spec.ts

      init-caps.pipe.spec.ts

Back to top

### {@a 02-11}_End-to-End_ (E2E) test file names

#### Style 02-11

**Do** name end-to-end test specification files after the feature they test with a suffix of `.e2e-spec`.

**Why?** Provides a consistent way to quickly identify end-to-end tests.

**Why?** Provides pattern matching for test runners and build automation.

  <col width="50%">

  </col>

  <col width="50%">

  </col>

      Symbol Name

      File Name

      End-to-End Tests

      app.e2e-spec.ts

      heroes.e2e-spec.ts

Back to top

### {@a 02-12}Angular _NgModule_ names

#### Style 02-12

**Do** append the symbol name with the suffix `Module`.

**Do** give the file name the `.module.ts` extension.

**Do** name the module after the feature and folder it resides in.

**Why?** Provides a consistent way to quickly identify and reference modules.

**Why?** Upper camel case is conventional for identifying objects that can be instantiated using a constructor.

**Why?** Easily identifies the module as the root of the same named feature.

**Do** suffix a _RoutingModule_ class name with `RoutingModule`.

**Do** end the filename of a _RoutingModule_ with `-routing.module.ts`.

**Why?** A `RoutingModule` is a module dedicated exclusively to configuring the Angular router.
A consistent class and file name convention make these modules easy to spot and verify.

  <col width="50%">

  </col>

  <col width="50%">

  </col>

      Symbol Name

      File Name

        @NgModule({ ... })
        export class AppModule { }

      app.module.ts

        @NgModule({ ... })
        export class HeroesModule { }

      heroes.module.ts

        @NgModule({ ... })
        export class VillainsModule { }

      villains.module.ts

        @NgModule({ ... })
        export class AppRoutingModule { }

      app-routing.module.ts

        @NgModule({ ... })
        export class HeroesRoutingModule { }

      heroes-routing.module.ts

Back to top

## Coding conventions

Have a consistent set of coding, naming, and whitespace conventions.

### {@a 03-01}Classes

#### Style 03-01

**Do** use upper camel case when naming classes.

**Why?** Follows conventional thinking for class names.

**Why?** Classes can be instantiated and construct an instance.
By convention, upper camel case indicates a constructable asset.

Back to top

### {@a 03-02}Constants

#### Style 03-02

**Do** declare variables with `const` if their values should not change during the application lifetime.

**Why?** Conveys to readers that the value is invariant.

**Why?** TypeScript helps enforce that intent by requiring immediate initialization and by
preventing subsequent re-assignment.

**Consider** spelling `const` variables in lower camel case.

**Why?** Lower camel case variable names (`heroRoutes`) are easier to read and understand
than the traditional UPPER_SNAKE_CASE names (`HERO_ROUTES`).

**Why?** The tradition of naming constants in UPPER_SNAKE_CASE reflects
an era before the modern IDEs that quickly reveal the `const` declaration.
TypeScript prevents accidental reassignment.

**Do** tolerate _existing_ `const` variables that are spelled in UPPER_SNAKE_CASE.

**Why?** The tradition of UPPER_SNAKE_CASE remains popular and pervasive,
especially in third party modules.
It is rarely worth the effort to change them at the risk of breaking existing code and documentation.

Back to top

### {@a 03-03}Interfaces

#### Style 03-03

**Do** name an interface using upper camel case.

**Consider** naming an interface without an `I` prefix.

**Consider** using a class instead of an interface.

**Why?** TypeScript guidelines
discourage the `I` prefix.

**Why?** A class alone is less code than a _class-plus-interface_.

**Why?** A class can act as an interface (use `implements` instead of `extends`).

**Why?** An interface-class can be a provider lookup token in Angular dependency injection.

Back to top

### {@a 03-04}Properties and methods

#### Style 03-04

**Do** use lower camel case to name properties and methods.

**Avoid** prefixing private properties and methods with an underscore.

**Why?** Follows conventional thinking for properties and methods.

**Why?** JavaScript lacks a true private property or method.

**Why?** TypeScript tooling makes it easy to identify private vs. public properties and methods.

Back to top

### {@a 03-06}Import line spacing

#### Style 03-06

**Consider** leaving one empty line between third party imports and application imports.

**Consider** listing import lines alphabetized by the module.

**Consider** listing destructured imported symbols alphabetically.

**Why?** The empty line separates _your_ stuff from _their_ stuff.

**Why?** Alphabetizing makes it easier to read and locate symbols.

Back to top

## Application structure and Angular modules

Have a near-term view of implementation and a long-term vision. Start small but keep in mind where the app is heading down the road.

All of the app's code goes in a folder named `src`.
All feature areas are in their own folder, with their own Angular module.

All content is one asset per file. Each component, service, and pipe is in its own file.
All third party vendor scripts are stored in another folder and not in the `src` folder.
You didn't write them and you don't want them cluttering `src`.
Use the naming conventions for files in this guide.
Back to top

### {@a 04-01}_LIFT_

#### Style 04-01

**Do** structure the app such that you can **L**ocate code quickly,
**I**dentify the code at a glance,
keep the **F**lattest structure you can, and
**T**ry to be DRY.

**Do** define the structure to follow these four basic guidelines, listed in order of importance.

**Why?** LIFT Provides a consistent structure that scales well, is modular, and makes it easier to increase developer efficiency by finding code quickly.
To confirm your intuition about a particular structure, ask:
_can I quickly open and start work in all of the related files for this feature_?

Back to top

### {@a 04-02}Locate

#### Style 04-02

**Do** make locating code intuitive, simple and fast.

**Why?** To work efficiently you must be able to find files quickly,
especially when you do not know (or do not remember) the file _names_.
Keeping related files near each other in an intuitive location saves time.
A descriptive folder structure makes a world of difference to you and the people who come after you.

Back to top

### {@a 04-03}Identify

#### Style 04-03

**Do** name the file such that you instantly know what it contains and represents.

**Do** be descriptive with file names and keep the contents of the file to exactly one component.

**Avoid** files with multiple components, multiple services, or a mixture.

**Why?** Spend less time hunting and pecking for code, and become more efficient.
Longer file names are far better than _short-but-obscure_ abbreviated names.

It may be advantageous to deviate from the _one-thing-per-file_ rule when
you have a set of small, closely-related features that are better discovered and understood
in a single file than as multiple files. Be wary of this loophole.

Back to top

### {@a 04-04}Flat

#### Style 04-04

**Do** keep a flat folder structure as long as possible.

**Consider** creating sub-folders when a folder reaches seven or more files.

**Consider** configuring the IDE to hide distracting, irrelevant files such as generated `.js` and `.js.map` files.

**Why?** No one wants to search for a file through seven levels of folders.
A flat structure is easy to scan.

On the other hand,
psychologists believe
that humans start to struggle when the number of adjacent interesting things exceeds nine.
So when a folder has ten or more files, it may be time to create subfolders.

Base your decision on your comfort level.
Use a flatter structure until there is an obvious value to creating a new folder.

Back to top

### {@a 04-05}_T-DRY_ (Try to be _DRY_)

#### Style 04-05

**Do** be DRY (Don't Repeat Yourself).

**Avoid** being so DRY that you sacrifice readability.

**Why?** Being DRY is important, but not crucial if it sacrifices the other elements of LIFT.
That's why it's called _T-DRY_.
For example, it's redundant to name a template `hero-view.component.html` because
with the `.html` extension, it is obviously a view.
But if something is not obvious or departs from a convention, then spell it out.

Back to top

### {@a 04-06}Overall structural guidelines

#### Style 04-06

**Do** start small but keep in mind where the app is heading down the road.

**Do** have a near term view of implementation and a long term vision.

**Do** put all of the app's code in a folder named `src`.

**Consider** creating a folder for a component when it has multiple accompanying files (`.ts`, `.html`, `.css` and `.spec`).

**Why?** Helps keep the app structure small and easy to maintain in the early stages, while being easy to evolve as the app grows.

**Why?** Components often have four files (e.g. `*.html`, `*.css`, `*.ts`, and `*.spec.ts`) and can clutter a folder quickly.

{@a file-tree}

Here is a compliant folder and file structure:

    <project root>

      src

        app

          core

            core.module.ts

            exception.service.ts|spec.ts

            user-profile.service.ts|spec.ts

          heroes

            hero

              hero.component.ts|html|css|spec.ts

            hero-list

              hero-list.component.ts|html|css|spec.ts

            shared

              hero-button.component.ts|html|css|spec.ts

              hero.model.ts

              hero.service.ts|spec.ts

            heroes.component.ts|html|css|spec.ts

            heroes.module.ts

            heroes-routing.module.ts

          shared

            shared.module.ts

            init-caps.pipe.ts|spec.ts

            text-filter.component.ts|spec.ts

            text-filter.service.ts|spec.ts

          villains

            villain

              ...

            villain-list

              ...

            shared

              ...

            villains.component.ts|html|css|spec.ts

            villains.module.ts

            villains-routing.module.ts

          app.component.ts|html|css|spec.ts

          app.module.ts

          app-routing.module.ts

        main.ts

        index.html

        ...

      node_modules/...

      ...

While components in dedicated folders are widely preferred,
another option for small apps is to keep components flat (not in a dedicated folder).
This adds up to four files to the existing folder, but also reduces the folder nesting.
Whatever you choose, be consistent.

Back to top

### {@a 04-07}_Folders-by-feature_ structure

#### Style 04-07

**Do** create folders named for the feature area they represent.

**Why?** A developer can locate the code and identify what each file represents
at a glance. The structure is as flat as it can be and there are no repetitive or redundant names.

**Why?** The LIFT guidelines are all covered.

**Why?** Helps reduce the app from becoming cluttered through organizing the
content and keeping them aligned with the LIFT guidelines.

**Why?** When there are a lot of files, for example 10+,
locating them is easier with a consistent folder structure
and more difficult in a flat structure.

**Do** create an Angular module for each feature area.

**Why?** Angular modules make it easy to lazy load routable features.

**Why?** Angular modules make it easier to isolate, test, and re-use features.

  Refer to this _folder and file structure_ example.

Back to top

### {@a 04-08}App _root module_

#### Style 04-08

**Do** create an Angular module in the app's root folder,
for example, in `/src/app`.

**Why?** Every app requires at least one root Angular module.

**Consider** naming the root module `app.module.ts`.

**Why?** Makes it easier to locate and identify the root module.

Back to top

### {@a 04-09}Feature modules

#### Style 04-09

**Do** create an Angular module for all distinct features in an application;
for example, a `Heroes` feature.

**Do** place the feature module in the same named folder as the feature area;
for example, in `app/heroes`.

**Do** name the feature module file reflecting the name of the feature area
and folder; for example, `app/heroes/heroes.module.ts`.

**Do** name the feature module symbol reflecting the name of the feature
area, folder, and file; for example, `app/heroes/heroes.module.ts` defines `HeroesModule`.

**Why?** A feature module can expose or hide its implementation from other modules.

**Why?** A feature module identifies distinct sets of related components that comprise the feature area.

**Why?** A feature module can easily be routed to both eagerly and lazily.

**Why?** A feature module defines clear boundaries between specific functionality and other application features.

**Why?** A feature module helps clarify and make it easier to assign development responsibilities to different teams.

**Why?** A feature module can easily be isolated for testing.

Back to top

### {@a 04-10}Shared feature module

#### Style 04-10

**Do** create a feature module named `SharedModule` in a `shared` folder;
for example, `app/shared/shared.module.ts` defines `SharedModule`.

**Do** declare components, directives, and pipes in a shared module when those
items will be re-used and referenced by the components declared in other feature modules.

**Consider** using the name SharedModule when the contents of a shared
module are referenced across the entire application.

**Avoid** providing services in shared modules. Services are usually
singletons that are provided once for the entire application or
in a particular feature module.

**Do** import all modules required by the assets in the `SharedModule`;
for example, `CommonModule` and `FormsModule`.

**Why?** `SharedModule` will contain components, directives and pipes
that may need features from another common module; for example,
`ngFor` in `CommonModule`.

**Do** declare all components, directives, and pipes in the `SharedModule`.

**Do** export all symbols from the `SharedModule` that other feature modules need to use.

**Why?** `SharedModule` exists to make commonly used components, directives and pipes available for use in the templates of components in many other modules.

**Avoid** specifying app-wide singleton providers in a `SharedModule`. Intentional singletons are OK. Take care.

**Why?** A lazy loaded feature module that imports that shared module will make its own copy of the service and likely have undesireable results.

**Why?** You don't want each module to have its own separate instance of singleton services.
Yet there is a real danger of that happening if the `SharedModule` provides a service.

    src

      app

        shared

          shared.module.ts

          init-caps.pipe.ts|spec.ts

          text-filter.component.ts|spec.ts

          text-filter.service.ts|spec.ts

        app.component.ts|html|css|spec.ts

        app.module.ts

        app-routing.module.ts

      main.ts

      index.html

    ...

Back to top

### {@a 04-11}Core feature module

#### Style 04-11

**Consider** collecting numerous, auxiliary, single-use classes inside a core module
to simplify the apparent structure of a feature module.

**Consider** calling the application-wide core module, `CoreModule`.
Importing `CoreModule` into the root `AppModule` reduces its complexity
and emphasizes its role as orchestrator of the application as a whole.

**Do** create a feature module named `CoreModule` in a `core` folder (e.g. `app/core/core.module.ts` defines `CoreModule`).

**Do** put a singleton service whose instance will be shared throughout the application in the `CoreModule` (e.g. `ExceptionService` and `LoggerService`).

**Do** import all modules required by the assets in the `CoreModule` (e.g. `CommonModule` and `FormsModule`).

**Why?** `CoreModule` provides one or more singleton services. Angular registers the providers with the app root injector, making a singleton instance of each service available to any component that needs them, whether that component is eagerly or lazily loaded.

**Why?** `CoreModule` will contain singleton services. When a lazy loaded module imports these, it will get a new instance and not the intended app-wide singleton.

**Do** gather application-wide, single use components in the `CoreModule`.
Import it once (in the `AppModule`) when the app starts and never import it anywhere else. (e.g. `NavComponent` and `SpinnerComponent`).

**Why?** Real world apps can have several single-use components (e.g., spinners, message toasts, and modal dialogs) that appear only in the `AppComponent` template.
They are not imported elsewhere so they're not shared in that sense.
Yet they're too big and messy to leave loose in the root folder.

**Avoid** importing the `CoreModule` anywhere except in the `AppModule`.

**Why?** A lazily loaded feature module that directly imports the `CoreModule` will make its own copy of services and likely have undesireable results.

**Why?** An eagerly loaded feature module already has access to the `AppModule`'s injector, and thus the `CoreModule`'s services.

**Do** export all symbols from the `CoreModule` that the `AppModule` will import and make available for other feature modules to use.

**Why?** `CoreModule` exists to make commonly used singleton services available for use in the many other modules.

**Why?** You want the entire app to use the one, singleton instance.
You don't want each module to have its own separate instance of singleton services.
Yet there is a real danger of that happening accidentally if the `CoreModule` provides a service.

    src

      app

        core

          core.module.ts

          logger.service.ts|spec.ts

          nav

            nav.component.ts|html|css|spec.ts

          spinner

            spinner.component.ts|html|css|spec.ts

            spinner.service.ts|spec.ts

        app.component.ts|html|css|spec.ts

        app.module.ts

        app-routing.module.ts

      main.ts

      index.html

    ...

`AppModule` is a little smaller because many app/root classes have moved to other modules.
`AppModule` is stable because you will add future components and providers to other modules, not this one.
`AppModule` delegates to imported modules rather than doing work.
`AppModule` is focused on its main task, orchestrating the app as a whole.

Back to top

### {@a 04-12}Prevent re-import of the core module

#### Style 04-12

Only the root `AppModule` should import the `CoreModule`.

**Do** guard against reimporting of `CoreModule` and fail fast by adding guard logic.

**Why?** Guards against reimporting of the `CoreModule`.

**Why?** Guards against creating multiple instances of assets intended to be singletons.

Back to top

### {@a 04-13}Lazy Loaded folders

#### Style 04-13

A distinct application feature or workflow may be *lazy loaded* or *loaded on demand* rather than when the application starts.

**Do** put the contents of lazy loaded features in a *lazy loaded folder*.
A typical *lazy loaded folder* contains a *routing component*, its child components, and their related assets and modules.

**Why?** The folder makes it easy to identify and isolate the feature content.

Back to top

### {@a 04-14}Never directly import lazy loaded folders

#### Style 04-14

**Avoid** allowing modules in sibling and parent folders to directly import a module in a *lazy loaded feature*.

**Why?** Directly importing and using a module will load it immediately when the intention is to load it on demand.

Back to top

## Components

### {@a 05-02}Component selector names

#### Style 05-02

**Do** use _dashed-case_ or _kebab-case_ for naming the element selectors of components.

**Why?** Keeps the element names consistent with the specification for [Custom Elements](https://www.w3.org/TR/custom-elements/).

Back to top

### {@a 05-03}Components as elements

#### Style 05-03

**Do** give components an _element_ selector, as opposed to _attribute_ or _class_ selectors.

**Why?** components have templates containing HTML and optional Angular template syntax.
They display content.
Developers place components on the page as they would native HTML elements and web components.

**Why?** It is easier to recognize that a symbol is a component by looking at the template's html.

Back to top

### {@a 05-04}Extract templates and styles to their own files

#### Style 05-04

**Do** extract templates and styles into a separate file, when more than 3 lines.

**Do** name the template file `[component-name].component.html`, where [component-name] is the component name.

**Do** name the style file `[component-name].component.css`, where [component-name] is the component name.

**Do** specify _component-relative_ URLs, prefixed with `./`.

**Why?** Large, inline templates and styles obscure the component's purpose and implementation, reducing readability and maintainability.

**Why?** In most editors, syntax hints and code snippets aren't available when developing inline templates and styles.
The Angular TypeScript Language Service (forthcoming) promises to overcome this deficiency for HTML templates
in those editors that support it; it won't help with CSS styles.

**Why?** A _component relative_ URL requires no change when you move the component files, as long as the files stay together.

**Why?** The `./` prefix is standard syntax for relative URLs; don't depend on Angular's current ability to do without that prefix.

Back to top

### {@a 05-12}Decorate _input_ and _output_ properties

#### Style 05-12

**Do** use the `@Input()` and `@Output()` class decorators instead of the `inputs` and `outputs` properties of the
`@Directive` and `@Component` metadata:

**Consider** placing `@Input()` or `@Output()` on the same line as the property it decorates.

**Why?** It is easier and more readable to identify which properties in a class are inputs or outputs.

**Why?** If you ever need to rename the property or event name associated with
`@Input` or `@Output`, you can modify it in a single place.

**Why?** The metadata declaration attached to the directive is shorter and thus more readable.

**Why?** Placing the decorator on the same line _usually_ makes for shorter code and still easily identifies the property as an input or output.
Put it on the line above when doing so is clearly more readable.

Back to top

### {@a 05-13}Avoid aliasing _inputs_ and _outputs_

#### Style 05-13

**Avoid** _input_ and _output_ aliases except when it serves an important purpose.

**Why?** Two names for the same property (one private, one public) is inherently confusing.

**Why?** You should use an alias when the directive name is also an _input_ property,
and the directive name doesn't describe the property.

Back to top

### {@a 05-14}Member sequence

#### Style 05-14

**Do** place properties up top followed by methods.

**Do** place private members after public members, alphabetized.

**Why?** Placing members in a consistent sequence makes it easy to read and
helps instantly identify which members of the component serve which purpose.

Back to top

### {@a 05-15}Delegate complex component logic to services

#### Style 05-15

**Do** limit logic in a component to only that required for the view. All other logic should be delegated to services.

**Do** move reusable logic to services and keep components simple and focused on their intended purpose.

**Why?** Logic may be reused by multiple components when placed within a service and exposed via a function.

**Why?** Logic in a service can more easily be isolated in a unit test, while the calling logic in the component can be easily mocked.

**Why?** Removes dependencies and hides implementation details from the component.

**Why?** Keeps the component slim, trim, and focused.

Back to top

### {@a 05-16}Don't prefix _output_ properties

#### Style 05-16

**Do** name events without the prefix `on`.

**Do** name event handler methods with the prefix `on` followed by the event name.

**Why?** This is consistent with built-in events such as button clicks.

**Why?** Angular allows for an [alternative syntax](guide/template-syntax#binding-syntax) `on-*`. If the event itself was prefixed with `on` this would result in an `on-onEvent` binding expression.

Back to top

### {@a 05-17}Put presentation logic in the component class

#### Style 05-17

**Do** put presentation logic in the component class, and not in the template.

**Why?** Logic will be contained in one place (the component class) instead of being spread in two places.

**Why?** Keeping the component's presentation logic in the class instead of the template improves testability, maintainability, and reusability.

Back to top

## Directives

### {@a 06-01}Use directives to enhance an element

#### Style 06-01

**Do** use attribute directives when you have presentation logic without a template.

**Why?** Attribute directives don't have an associated template.

**Why?** An element may have more than one attribute directive applied.

Back to top

### {@a 06-03}_HostListener_/_HostBinding_ decorators versus _host_ metadata

#### Style 06-03

**Consider** preferring the `@HostListener` and `@HostBinding` to the
`host` property of the `@Directive` and `@Component` decorators.

**Do** be consistent in your choice.

**Why?** The property associated with `@HostBinding` or the method associated with `@HostListener`
can be modified only in a single place—in the directive's class.
If you use the `host` metadata property, you must modify both the property declaration inside the controller,
and the metadata associated with the directive.

Compare with the less preferred `host` metadata alternative.

**Why?** The `host` metadata is only one term to remember and doesn't require extra ES imports.

Back to top

## Services

### {@a 07-01}Services are singletons

#### Style 07-01

**Do** use services as singletons within the same injector. Use them for sharing data and functionality.

**Why?** Services are ideal for sharing methods across a feature area or an app.

**Why?** Services are ideal for sharing stateful in-memory data.

Back to top

### {@a 07-02}Single responsibility

#### Style 07-02

**Do** create services with a single responsibility that is encapsulated by its context.

**Do** create a new service once the service begins to exceed that singular purpose.

**Why?** When a service has multiple responsibilities, it becomes difficult to test.

**Why?** When a service has multiple responsibilities, every component or service that injects it now carries the weight of them all.

Back to top

### {@a 07-03}Providing a service

#### Style 07-03

**Do** provide services to the Angular injector at the top-most component where they will be shared.

**Why?** The Angular injector is hierarchical.

**Why?** When providing the service to a top level component,
that instance is shared and available to all child components of that top level component.

**Why?** This is ideal when a service is sharing methods or state.

**Why?** This is not ideal when two different components need different instances of a service. In this scenario it would be better to provide the service at the component level that needs the new and separate instance.

Back to top

### {@a 07-04}Use the @Injectable() class decorator

#### Style 07-04

**Do** use the `@Injectable()` class decorator instead of the `@Inject` parameter decorator when using types as tokens for the dependencies of a service.

**Why?** The Angular Dependency Injection (DI) mechanism resolves a service's own
dependencies based on the declared types of that service's constructor parameters.

**Why?** When a service accepts only dependencies associated with type tokens, the `@Injectable()` syntax is much less verbose compared to using `@Inject()` on each individual constructor parameter.

Back to top

## Data Services

### {@a 08-01}Talk to the server through a service

#### Style 08-01

**Do** refactor logic for making data operations and interacting with data to a service.

**Do** make data services responsible for XHR calls, local storage, stashing in memory, or any other data operations.

**Why?** The component's responsibility is for the presentation and gathering of information for the view. It should not care how it gets the data, just that it knows who to ask for it. Separating the data services moves the logic on how to get it to the data service, and lets the component be simpler and more focused on the view.

**Why?** This makes it easier to test (mock or real) the data calls when testing a component that uses a data service.

**Why?** The details of data management, such as headers, HTTP methods,
caching, error handling, and retry logic, are irrelevant to components
and other data consumers.

A data service encapsulates these details. It's easier to evolve these
details inside the service without affecting its consumers. And it's
easier to test the consumers with mock service implementations.

Back to top

## Lifecycle hooks

Use Lifecycle hooks to tap into important events exposed by Angular.
Back to top

### {@a 09-01}Implement lifecycle hook interfaces

#### Style 09-01

**Do** implement the lifecycle hook interfaces.

**Why?** Lifecycle interfaces prescribe typed method
signatures. use those signatures to flag spelling and syntax mistakes.

Back to top

## Appendix

Useful tools and tips for Angular.
Back to top

### {@a A-01}Codelyzer

#### Style A-01

**Do** use [codelyzer](https://www.npmjs.com/package/codelyzer) to follow this guide.

**Consider** adjusting the rules in codelyzer to suit your needs.

Back to top

### {@a A-02}File templates and snippets

#### Style A-02

**Do** use file templates or snippets to help follow consistent styles and patterns. Here are templates and/or snippets for some of the web development editors and IDEs.

**Consider** using [snippets](https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular2) for [Visual Studio Code](https://code.visualstudio.com/) that follow these styles and guidelines.

**Consider** using [snippets](https://atom.io/packages/angular-2-typescript-snippets) for [Atom](https://atom.io/) that follow these styles and guidelines.

**Consider** using [snippets](https://github.com/orizens/sublime-angular2-snippets) for [Sublime Text](http://www.sublimetext.com/) that follow these styles and guidelines.

**Consider** using [snippets](https://github.com/mhartington/vim-angular2-snippets) for [Vim](http://www.vim.org/) that follow these styles and guidelines.

Back to top


text:
Harmonogram zadań crona

Wprowadzenie do zadań Crona

Zadanie Cron to polecenie, które jest okresowo uruchamiane w systemie


text:
.PHONY: scheduling clean

scheduling:
	sh build-evolve.sh
	$(MAKE) -C scheduling

all: scheduling

default: all

clean:
	rm -rf scheduling/bin
	rm -rf scheduling/jobshop/exercises/results
	rm -rf scheduling/ci/results


text:
chromium-browser --new-window \
  http://inbox.google.com


text:
import * as e from '../contracts/error';

export namespace SpotOptimization {
    export class SpotOptimizationError implements Error {
        public message = "optimization error, see the appError property for more details.";
        public name = "Spot Optimization Error";

        constructor(public appError: e.Contracts.Error) { }
    }
}


text:
<head>

  <title>
    {% if page.title == "Home" %}
      {{ site.data.settings.title }} | {{ site.data.settings.tagline }}
    {% else %}
      {{ page.title }} | {{ site.data.settings.title }}
    {% endif %}
  </title>

  <meta name="viewport" content="width=device-width, initial-scale=1">

  <link rel="stylesheet" href="{{ site.github.url }}/assets/css/main.css">
  <link rel="stylesheet" href="{{ site.github.url }}/assets/css/syntax.css">
  <!-- RSS-v2.0
  <link href="{{ site.github.url }}/feed.xml" type="application/rss+xml" rel="alternate" title="{{ site.data.settings.title }} | {{ site.data.settings.tagline }}"/>
  //-->

  <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=PT+Serif:400,400italic,700%7CPT+Sans:400">
  <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Source+Code+Pro">
  <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Quattrocento+Sans">
  <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">

  <script type="text/javascript" async
    src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-MML-AM_CHTML">
  </script>

  {% include google-analytics.html %}
  <!-- Use Atom -->
  {% feed_meta %}
	  <script>
	  function up() {
    var e = Math.max(document.body.scrollTop, document.documentElement.scrollTop);
    return e > 0 ? (window.scrollBy(0, (e + 100) / -10), t = setTimeout("up()", 20)) : clearTimeout(t), !1;
}
window.onscroll = function myScroll() {
    var toTop = document.querySelector(".to-top");
   (document.body.scrollTop > 0 || document.documentElement.scrollTop > 0) ? toTop.style.display='block' : toTop.removeAttribute('style');
}
	  </script>
</head>


text:
.class Lcom/android/server/hdmi/HdmiControlService$5;
.super Ljava/lang/Object;
.source "HdmiControlService.java"

# interfaces
.implements Lcom/android/server/hdmi/HdmiCecLocalDevice$PendingActionClearedCallback;

# annotations
.annotation system Ldalvik/annotation/EnclosingMethod;
    value = Lcom/android/server/hdmi/HdmiControlService;->disableHdmiControlService()V
.end annotation

.annotation system Ldalvik/annotation/InnerClass;
    accessFlags = 0x0
    name = null
.end annotation

# instance fields
.field final synthetic this$0:Lcom/android/server/hdmi/HdmiControlService;

# direct methods
.method constructor <init>(Lcom/android/server/hdmi/HdmiControlService;)V
    .locals 0

    .prologue
    .line 2206
    iput-object p1, p0, Lcom/android/server/hdmi/HdmiControlService$5;->this$0:Lcom/android/server/hdmi/HdmiControlService;

    invoke-direct {p0}, Ljava/lang/Object;-><init>()V

    return-void
.end method

# virtual methods
.method public onCleared(Lcom/android/server/hdmi/HdmiCecLocalDevice;)V
    .locals 2
    .param p1, "device"    # Lcom/android/server/hdmi/HdmiCecLocalDevice;

    .prologue
    .line 2209
    iget-object v0, p0, Lcom/android/server/hdmi/HdmiControlService$5;->this$0:Lcom/android/server/hdmi/HdmiControlService;

    # invokes: Lcom/android/server/hdmi/HdmiControlService;->assertRunOnServiceThread()V
    invoke-static {v0}, Lcom/android/server/hdmi/HdmiControlService;->access$000(Lcom/android/server/hdmi/HdmiControlService;)V

    .line 2210
    iget-object v0, p0, Lcom/android/server/hdmi/HdmiControlService$5;->this$0:Lcom/android/server/hdmi/HdmiControlService;

    # getter for: Lcom/android/server/hdmi/HdmiControlService;->mCecController:Lcom/android/server/hdmi/HdmiCecController;
    invoke-static {v0}, Lcom/android/server/hdmi/HdmiControlService;->access$1400(Lcom/android/server/hdmi/HdmiControlService;)Lcom/android/server/hdmi/HdmiCecController;

    move-result-object v0

    new-instance v1, Lcom/android/server/hdmi/HdmiControlService$5$1;

    invoke-direct {v1, p0}, Lcom/android/server/hdmi/HdmiControlService$5$1;-><init>(Lcom/android/server/hdmi/HdmiControlService$5;)V

    invoke-virtual {v0, v1}, Lcom/android/server/hdmi/HdmiCecController;->flush(Ljava/lang/Runnable;)V

    .line 2218
    return-void
.end method


text:
package com.bosong.commentgallery;

import android.content.Intent;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;

import com.bosong.commentgallerylib.CommentGalleryContainer;
import com.bosong.commentgallerylib.CommentImageGrid;

import java.util.Arrays;
import java.util.List;

public class MainActivity extends AppCompatActivity{

    public static final String CLICK_INDEX = "CLICK_INDEX";
    public static final String COMMENT_LIST = "COMMENT_LIST";
    private static final String[] SAMPLE_URIS = {
            "https://images-cn.ssl-images-amazon.com/images/I/81ghN3jk6AL._SL1000_.jpg",
            "https://images-cn.ssl-images-amazon.com/images/I/61YK4KgVWLL._SL1000_.jpg",
            "https://images-cn.ssl-images-amazon.com/images/I/81v6YVUdLnL._SL1000_.jpg",
            "https://images-cn.ssl-images-amazon.com/images/I/61y10jAltmL._SL1000_.jpg",
            "https://images-cn.ssl-images-amazon.com/images/I/71owNXqWERL._SL1000_.jpg",
            "https://images-cn.ssl-images-amazon.com/images/G/28/aplus_rbs/iPhone6PC_170223.jpg",
            "https://images-cn.ssl-images-amazon.com/images/G/28/kindle/2016/zhangr/DPfeature_img/voyag_featureimg._CB532421748_.jpg"
    };
    private static final String SAMPLE_COMMENT = "I am somewhat disappointed in the 2015 version as there is not a huge improvement over last year's model. ";

    private CommentImageGrid mCommentGrid;

    CommentGalleryContainer commentList;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        mCommentGrid = (CommentImageGrid) findViewById(R.id.comment_grid);

        List<String> urls = Arrays.asList(SAMPLE_URIS);

        commentList = new CommentGalleryContainer(urls, SAMPLE_COMMENT);

        mCommentGrid.setData(urls);
        mCommentGrid.setOnItemClickListener(new CommentImageGrid.OnItemClickListener() {
            @Override
            public void OnItemClick(int position) {
                Intent it = new Intent();
                it.putExtra(CLICK_INDEX, position);
                it.putExtra(COMMENT_LIST, commentList);
                it.setClass(MainActivity.this, CommentGalleryActivity.class);
                startActivity(it);
            }
        });
    }
}


text:
package main.common;

import java.awt.*;

public interface Drawable {

    /**
     * Draws the shape of the geometric object
     *
     * @param g Graphics object
     */
    void draw(Graphics2D g);

    /**
     * Draw the caption of the geometric object.
     *
     * @param g Graphics object
     */
    void drawCaption(Graphics2D g);

}


text:
namespace Sogeti.Academy.Application.Presentations.Commands.Add
{
    public class AddPresentationViewModel
    {
        public string Topic { get; set; }
        public string Description { get; set; }

        public AddFileViewModel[] Files { get; set; }
    }
}


text:
package controller

import (
	"testing"

	kapi "k8s.io/kubernetes/pkg/api"
	"k8s.io/kubernetes/pkg/util/sets"
	"k8s.io/kubernetes/pkg/watch"

	routeapi "github.com/openshift/origin/pkg/route/api"
)

type fakeRouterPlugin struct {
	lastSyncProcessed bool
	syncedAtLeastOnce bool
}

func (p *fakeRouterPlugin) HandleRoute(t watch.EventType, route *routeapi.Route) error {
	return nil
}
func (p *fakeRouterPlugin) HandleNode(t watch.EventType, node *kapi.Node) error {
	return nil
}
func (p *fakeRouterPlugin) HandleEndpoints(watch.EventType, *kapi.Endpoints) error {
	return nil
}
func (p *fakeRouterPlugin) HandleNamespaces(namespaces sets.String) error {
	return nil
}

func (p *fakeRouterPlugin) SetLastSyncProcessed(processed bool) error {
	p.lastSyncProcessed = processed
	return nil
}

func (p *fakeRouterPlugin) SetSyncedAtLeastOnce() error {
	p.syncedAtLeastOnce = true
	return nil
}

type fakeNamespaceLister struct {
}

func (n fakeNamespaceLister) NamespaceNames() (sets.String, error) {
	return sets.NewString("foo"), nil
}

func TestRouterController_updateLastSyncProcessed(t *testing.T) {
	p := fakeRouterPlugin{}
	routesListConsumed := true
	c := RouterController{
		Plugin: &p,
		NextEndpoints: func() (watch.EventType, *kapi.Endpoints, error) {
			return watch.Modified, &kapi.Endpoints{}, nil
		},
		NextRoute: func() (watch.EventType, *routeapi.Route, error) {
			return watch.Modified, &routeapi.Route{}, nil
		},
		NextNode: func() (watch.EventType, *kapi.Node, error) {
			return watch.Modified, &kapi.Node{}, nil
		},
		EndpointsListConsumed: func() bool {
			return true
		},
		RoutesListConsumed: func() bool {
			return routesListConsumed
		},
		Namespaces:       fakeNamespaceLister{},
		NamespaceRetries: 1,
	}

	// Simulate the initial sync
	c.HandleNamespaces()
	if p.lastSyncProcessed {
		t.Fatalf("last sync not expected to have been processed")
	}
	c.HandleEndpoints()
	if p.lastSyncProcessed {
		t.Fatalf("last sync not expected to have been processed")
	}
	c.HandleRoute()
	if !p.lastSyncProcessed {
		t.Fatalf("last sync expected to have been processed")
	}

	// Simulate a relist
	routesListConsumed = false
	c.HandleRoute()
	if p.lastSyncProcessed {
		t.Fatalf("last sync not expected to have been processed")
	}
	routesListConsumed = true
	c.HandleRoute()
	if !p.lastSyncProcessed {
		t.Fatalf("last sync expected to have been processed")
	}

}


text:
package io.debezium.antlr;

import java.util.Arrays;
import java.util.Collections;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import org.antlr.v4.runtime.ParserRuleContext;
import org.antlr.v4.runtime.tree.TerminalNode;

import io.debezium.annotation.Immutable;
import io.debezium.annotation.ThreadSafe;
import io.debezium.relational.Column;
import io.debezium.relational.ddl.DataType;
import io.debezium.relational.ddl.DataTypeBuilder;
import io.debezium.text.ParsingException;

/**
 * A resolver for DBMS data types.
 *
 * Its main purpose is to match corresponding JDBC data type, resolve a name of parsed data type,
 * and optionally predefine default values for length and scale for DBMS data type.
 *
 * @author Roman Kuchár <kucharrom@gmail.com>.
 */
@ThreadSafe
@Immutable
public class DataTypeResolver {

    private final Map<String, List<DataTypeEntry>> contextDataTypesMap;

    private DataTypeResolver(Map<String, List<DataTypeEntry>> contextDataTypesMap) {
        this.contextDataTypesMap = Collections.unmodifiableMap(contextDataTypesMap);
    }

    /**
     * Resolves a data type from given parsed context.
     *
     * @param dataTypeContext parse context; may not e null
     * @return instance of {@link DataType}, which will holds matched JDBC type, name and default values for length and scale.
     */
    public DataType resolveDataType(ParserRuleContext dataTypeContext) {
        DataType dataType = null;
        // use priority according to number of matched tokens
        int selectedTypePriority = -1;

        for (DataTypeEntry dataTypeEntry : contextDataTypesMap.get(dataTypeContext.getClass().getCanonicalName())) {
            int dataTypePriority = dataTypeEntry.getDbmsDataTypeTokenIdentifiers().length;
            if (dataTypePriority > selectedTypePriority) {
                DataTypeBuilder dataTypeBuilder = new DataTypeBuilder();
                boolean correctDataType = true;
                for (Integer mainTokenIdentifier : dataTypeEntry.getDbmsDataTypeTokenIdentifiers()) {
                    TerminalNode token = dataTypeContext.getToken(mainTokenIdentifier, 0);
                    if (correctDataType) {
                        if (token == null) {
                            correctDataType = false;
                        }
                        else {
                            dataTypeBuilder.addToName(token.getText());
                        }
                    }
                }
                if (correctDataType) {
                    dataType = buildDataType(dataTypeContext, dataTypeEntry, dataTypeBuilder);
                    selectedTypePriority = dataTypePriority;
                }
            }
        }
        if (dataType == null) {
            throw new ParsingException(null, "Unrecognized dataType for " + AntlrDdlParser.getText(dataTypeContext));
        }
        return dataType;
    }

    private DataType buildDataType(ParserRuleContext dataTypeContext, DataTypeEntry dataTypeEntry, DataTypeBuilder dataTypeBuilder) {
        addOptionalSuffixToName(dataTypeContext, dataTypeEntry, dataTypeBuilder);
        dataTypeBuilder.jdbcType(dataTypeEntry.getJdbcDataType());
        dataTypeBuilder.length(dataTypeEntry.getDefaultLength());
        dataTypeBuilder.scale(dataTypeEntry.getDefaultScale());

        return dataTypeBuilder.create();
    }

    private void addOptionalSuffixToName(ParserRuleContext dataTypeContext, DataTypeEntry dataTypeEntry, DataTypeBuilder dataTypeBuilder) {
        if (dataTypeEntry.getSuffixTokens() != null) {
            for (Integer suffixTokenIdentifier : dataTypeEntry.getSuffixTokens()) {
                if (dataTypeContext.getToken(suffixTokenIdentifier, 0) != null) {
                    dataTypeBuilder.addToName(dataTypeContext.getToken(suffixTokenIdentifier, 0).getText());
                }
            }
        }
    }

    public static class Builder {

        private final Map<String, List<DataTypeEntry>> contextDataTypesMap = new HashMap<>();

        /**
         * Registers a data type entries, which will be used for resolving phase.
         *
         * @param contextClassCanonicalName canonical name of context instance, in which the data type entry will appear; may not be null
         * @param dataTypeEntries list of {@link DataTypeEntry} definitions; may not be null
         */
        public void registerDataTypes(String contextClassCanonicalName, List<DataTypeEntry> dataTypeEntries) {
            contextDataTypesMap.put(contextClassCanonicalName, Collections.unmodifiableList(dataTypeEntries));
        }

        public DataTypeResolver build() {
            return new DataTypeResolver(contextDataTypesMap);
        }
    }

    /**
     * DTO class for definition of data type.
     */
    public static class DataTypeEntry {

        /**
         * The corresponding JDBC data type
         */
        private final int jdbcDataType;
        /**
         * Token identifiers for DBMS data type
         */
        private final Integer[] dbmsDataTypeTokenIdentifiers;
        /**
         * Token identifiers for optional suffix tokens for DBMS data type.
         */
        private Integer[] suffixTokens = null;
        private int defaultLength = Column.UNSET_INT_VALUE;
        private int defaultScale = Column.UNSET_INT_VALUE;

        public DataTypeEntry(int jdbcDataType, Integer... dbmsDataTypeTokenIdentifiers) {
            this.dbmsDataTypeTokenIdentifiers = dbmsDataTypeTokenIdentifiers;
            this.jdbcDataType = jdbcDataType;
        }

        Integer[] getDbmsDataTypeTokenIdentifiers() {
            return dbmsDataTypeTokenIdentifiers;
        }

        int getJdbcDataType() {
            return jdbcDataType;
        }

        Integer[] getSuffixTokens() {
            return suffixTokens;
        }

        int getDefaultLength() {
            return defaultLength;
        }

        int getDefaultScale() {
            return defaultScale;
        }

        /**
         * Sets an optional suffix tokens that may appear in DBMS data type definition.
         *
         * @param suffixTokens optional suffix tokens.
         * @return instance of this class, so the calls may be chained.
         */
        public DataTypeEntry setSuffixTokens(Integer... suffixTokens) {
            this.suffixTokens = suffixTokens;
            return this;
        }

        /**
         * Set a default length for data type.
         *
         * @param defaultLength default length for data type.
         * @return instance of this class, so the calls may be chained.
         */
        public DataTypeEntry setDefaultLengthDimension(int defaultLength) {
            this.defaultLength = defaultLength;
            return this;
        }

        /**
         * Set a default length and scale for data type.
         *
         * @param defaultLength default length for data type.
         * @param defaultScale default scale for data type.
         * @return instance of this class, so the calls may be chained.
         */
        public DataTypeEntry setDefaultLengthScaleDimension(int defaultLength, int defaultScale) {
            this.defaultLength = defaultLength;
            this.defaultScale = defaultScale;
            return this;
        }

        @Override
        public String toString() {
            return "DataTypeEntry [jdbcDataType=" + jdbcDataType + ", dbmsDataTypeTokenIdentifiers="
                    + Arrays.toString(dbmsDataTypeTokenIdentifiers) + ", suffixTokens=" + Arrays.toString(suffixTokens)
                    + ", defaultLength=" + defaultLength + ", defaultScale=" + defaultScale + "]";
        }
    }
}


text:
from .. import mfpackage
from ..data.mfdatautil import ListTemplateGenerator

class ModflowGwfwel(mfpackage.MFPackage):
    """
    ModflowGwfwel defines a wel package within a gwf6 model.

    Parameters
    ----------
    model : MFModel
        Model that this package is a part of.  Package is automatically
        added to model when it is initialized.
    loading_package : bool
        Do not set this parameter. It is intended for debugging and internal
        processing purposes only.
    auxiliary : [string]
        * auxiliary (string) defines an array of one or more auxiliary variable
          names. There is no limit on the number of auxiliary variables that
          can be provided on this line; however, lists of information provided
          in subsequent blocks must have a column of data for each auxiliary
          variable name defined here. The number of auxiliary variables
          detected on this line determines the value for naux. Comments cannot
          be provided anywhere on this line as they will be interpreted as
          auxiliary variable names. Auxiliary variables may not be used by the
          package, but they will be available for use by other parts of the
          program. The program will terminate with an error if auxiliary
          variables are specified on more than one line in the options block.
    auxmultname : string
        * auxmultname (string) name of auxiliary variable to be used as
          multiplier of well flow rate.
    boundnames : boolean
        * boundnames (boolean) keyword to indicate that boundary names may be
          provided with the list of well cells.
    print_input : boolean
        * print_input (boolean) keyword to indicate that the list of well
          information will be written to the listing file immediately after it
          is read.
    print_flows : boolean
        * print_flows (boolean) keyword to indicate that the list of well flow
          rates will be printed to the listing file for every stress period
          time step in which "BUDGET PRINT" is specified in Output Control. If
          there is no Output Control option and "PRINT_FLOWS" is specified,
          then flow rates are printed for the last time step of each stress
          period.
    save_flows : boolean
        * save_flows (boolean) keyword to indicate that well flow terms will be
          written to the file specified with "BUDGET FILEOUT" in Output
          Control.
    auto_flow_reduce : double
        * auto_flow_reduce (double) keyword and real value that defines the
          fraction of the cell thickness used as an interval for smoothly
          adjusting negative pumping rates to 0 in cells with head values less
          than or equal to the bottom of the cell. Negative pumping rates are
          adjusted to 0 or a smaller negative value when the head in the cell
          is equal to or less than the calculated interval above the cell
          bottom. AUTO_FLOW_REDUCE is set to 0.1 if the specified value is less
          than or equal to zero. By default, negative pumping rates are not
          reduced during a simulation.
    afrcsv_filerecord : [afrcsvfile]
        * afrcsvfile (string) name of the comma-separated value (CSV) output
          file to write information about well extraction rates that have been
          reduced by the program. Entries are only written if the extraction
          rates are reduced.
    timeseries : {varname:data} or timeseries data
        * Contains data for the ts package. Data can be stored in a dictionary
          containing data for the ts package with variable names as keys and
          package data as values. Data just for the timeseries variable is also
          acceptable. See ts package documentation for more information.
    observations : {varname:data} or continuous data
        * Contains data for the obs package. Data can be stored in a dictionary
          containing data for the obs package with variable names as keys and
          package data as values. Data just for the observations variable is
          also acceptable. See obs package documentation for more information.
    mover : boolean
        * mover (boolean) keyword to indicate that this instance of the Well
          Package can be used with the Water Mover (MVR) Package. When the
          MOVER option is specified, additional memory is allocated within the
          package to store the available, provided, and received water.
    maxbound : integer
        * maxbound (integer) integer value specifying the maximum number of
          wells cells that will be specified for use during any stress period.
    stress_period_data : [cellid, q, aux, boundname]
        * cellid ((integer, ...)) is the cell identifier, and depends on the
          type of grid that is used for the simulation. For a structured grid
          that uses the DIS input file, CELLID is the layer, row, and column.
          For a grid that uses the DISV input file, CELLID is the layer and
          CELL2D number. If the model uses the unstructured discretization
          (DISU) input file, CELLID is the node number for the cell. This
          argument is an index variable, which means that it should be treated
          as zero-based when working with FloPy and Python. Flopy will
          automatically subtract one when loading index variables and add one
          when writing index variables.
        * q (double) is the volumetric well rate. A positive value indicates
          recharge (injection) and a negative value indicates discharge
          (extraction). If the Options block includes a TIMESERIESFILE entry
          (see the "Time-Variable Input" section), values can be obtained from
          a time series by entering the time-series name in place of a numeric
          value.
        * aux (double) represents the values of the auxiliary variables for
          each well. The values of auxiliary variables must be present for each
          well. The values must be specified in the order of the auxiliary
          variables specified in the OPTIONS block. If the package supports
          time series and the Options block includes a TIMESERIESFILE entry
          (see the "Time-Variable Input" section), values can be obtained from
          a time series by entering the time-series name in place of a numeric
          value.
        * boundname (string) name of the well cell. BOUNDNAME is an ASCII
          character variable that can contain as many as 40 characters. If
          BOUNDNAME contains spaces in it, then the entire name must be
          enclosed within single quotes.
    filename : String
        File name for this package.
    pname : String
        Package name for this package.
    parent_file : MFPackage
        Parent package file that references this package. Only needed for
        utility packages (mfutl*). For example, mfutllaktab package must have
        a mfgwflak package parent_file.

    """

    auxiliary = ListTemplateGenerator(("gwf6", "wel", "options", "auxiliary"))
    afrcsv_filerecord = ListTemplateGenerator(
        ("gwf6", "wel", "options", "afrcsv_filerecord")
    )
    ts_filerecord = ListTemplateGenerator(
        ("gwf6", "wel", "options", "ts_filerecord")
    )
    obs_filerecord = ListTemplateGenerator(
        ("gwf6", "wel", "options", "obs_filerecord")
    )
    stress_period_data = ListTemplateGenerator(
        ("gwf6", "wel", "period", "stress_period_data")
    )
    package_abbr = "gwfwel"
    _package_type = "wel"
    dfn_file_name = "gwf-wel.dfn"

    dfn = [
        [
            "header",
            "multi-package",
        ],
        [
            "block options",
            "name auxiliary",
            "type string",
            "shape (naux)",
            "reader urword",
            "optional true",
        ],
        [
            "block options",
            "name auxmultname",
            "type string",
            "shape",
            "reader urword",
            "optional true",
        ],
        [
            "block options",
            "name boundnames",
            "type keyword",
            "shape",
            "reader urword",
            "optional true",
        ],
        [
            "block options",
            "name print_input",
            "type keyword",
            "reader urword",
            "optional true",
        ],
        [
            "block options",
            "name print_flows",
            "type keyword",
            "reader urword",
            "optional true",
        ],
        [
            "block options",
            "name save_flows",
            "type keyword",
            "reader urword",
            "optional true",
        ],
        [
            "block options",
            "name auto_flow_reduce",
            "type double precision",
            "reader urword",
            "optional true",
        ],
        [
            "block options",
            "name afrcsv_filerecord",
            "type record auto_flow_reduce_csv fileout afrcsvfile",
            "shape",
            "reader urword",
            "tagged true",
            "optional true",
        ],
        [
            "block options",
            "name auto_flow_reduce_csv",
            "type keyword",
            "shape",
            "in_record true",
            "reader urword",
            "tagged true",
            "optional false",
        ],
        [
            "block options",
            "name fileout",
            "type keyword",
            "shape",
            "in_record true",
            "reader urword",
            "tagged true",
            "optional false",
        ],
        [
            "block options",
            "name afrcsvfile",
            "type string",
            "preserve_case true",
            "shape",
            "in_record true",
            "reader urword",
            "tagged false",
            "optional false",
        ],
        [
            "block options",
            "name ts_filerecord",
            "type record ts6 filein ts6_filename",
            "shape",
            "reader urword",
            "tagged true",
            "optional true",
            "construct_package ts",
            "construct_data timeseries",
            "parameter_name timeseries",
        ],
        [
            "block options",
            "name ts6",
            "type keyword",
            "shape",
            "in_record true",
            "reader urword",
            "tagged true",
            "optional false",
        ],
        [
            "block options",
            "name filein",
            "type keyword",
            "shape",
            "in_record true",
            "reader urword",
            "tagged true",
            "optional false",
        ],
        [
            "block options",
            "name ts6_filename",
            "type string",
            "preserve_case true",
            "in_record true",
            "reader urword",
            "optional false",
            "tagged false",
        ],
        [
            "block options",
            "name obs_filerecord",
            "type record obs6 filein obs6_filename",
            "shape",
            "reader urword",
            "tagged true",
            "optional true",
            "construct_package obs",
            "construct_data continuous",
            "parameter_name observations",
        ],
        [
            "block options",
            "name obs6",
            "type keyword",
            "shape",
            "in_record true",
            "reader urword",
            "tagged true",
            "optional false",
        ],
        [
            "block options",
            "name obs6_filename",
            "type string",
            "preserve_case true",
            "in_record true",
            "tagged false",
            "reader urword",
            "optional false",
        ],
        [
            "block options",
            "name mover",
            "type keyword",
            "tagged true",
            "reader urword",
            "optional true",
        ],
        [
            "block dimensions",
            "name maxbound",
            "type integer",
            "reader urword",
            "optional false",
        ],
        [
            "block period",
            "name iper",
            "type integer",
            "block_variable True",
            "in_record true",
            "tagged false",
            "shape",
            "valid",
            "reader urword",
            "optional false",
        ],
        [
            "block period",
            "name stress_period_data",
            "type recarray cellid q aux boundname",
            "shape (maxbound)",
            "reader urword",
        ],
        [
            "block period",
            "name cellid",
            "type integer",
            "shape (ncelldim)",
            "tagged false",
            "in_record true",
            "reader urword",
        ],
        [
            "block period",
            "name q",
            "type double precision",
            "shape",
            "tagged false",
            "in_record true",
            "reader urword",
            "time_series true",
        ],
        [
            "block period",
            "name aux",
            "type double precision",
            "in_record true",
            "tagged false",
            "shape (naux)",
            "reader urword",
            "optional true",
            "time_series true",
        ],
        [
            "block period",
            "name boundname",
            "type string",
            "shape",
            "tagged false",
            "in_record true",
            "reader urword",
            "optional true",
        ],
    ]

    def __init__(
        self,
        model,
        loading_package=False,
        auxiliary=None,
        auxmultname=None,
        boundnames=None,
        print_input=None,
        print_flows=None,
        save_flows=None,
        auto_flow_reduce=None,
        afrcsv_filerecord=None,
        timeseries=None,
        observations=None,
        mover=None,
        maxbound=None,
        stress_period_data=None,
        filename=None,
        pname=None,
        parent_file=None,
    ):
        super().__init__(
            model, "wel", filename, pname, loading_package, parent_file
        )

        # set up variables
        self.auxiliary = self.build_mfdata("auxiliary", auxiliary)
        self.auxmultname = self.build_mfdata("auxmultname", auxmultname)
        self.boundnames = self.build_mfdata("boundnames", boundnames)
        self.print_input = self.build_mfdata("print_input", print_input)
        self.print_flows = self.build_mfdata("print_flows", print_flows)
        self.save_flows = self.build_mfdata("save_flows", save_flows)
        self.auto_flow_reduce = self.build_mfdata(
            "auto_flow_reduce", auto_flow_reduce
        )
        self.afrcsv_filerecord = self.build_mfdata(
            "afrcsv_filerecord", afrcsv_filerecord
        )
        self._ts_filerecord = self.build_mfdata("ts_filerecord", None)
        self._ts_package = self.build_child_package(
            "ts", timeseries, "timeseries", self._ts_filerecord
        )
        self._obs_filerecord = self.build_mfdata("obs_filerecord", None)
        self._obs_package = self.build_child_package(
            "obs", observations, "continuous", self._obs_filerecord
        )
        self.mover = self.build_mfdata("mover", mover)
        self.maxbound = self.build_mfdata("maxbound", maxbound)
        self.stress_period_data = self.build_mfdata(
            "stress_period_data", stress_period_data
        )
        self._init_complete = True


text:
    <title>Parameter </title>
    <link rel="stylesheet" href="../lib/bootstrap/bootstrap.css">
    <link rel="stylesheet" href="../params.css">

    %(page_content)s