Merge branch 'release/0.1.0'

.cirrus.yml

@@ -8,4 +8,8 @@ test_task:
     folder: ~/.pub-cache
   test_script: flutter test --coverage
   codecov_script:
-    - bash <(curl -s https://codecov.io/bash) -t $CODE_COV_TOKEN
+    - bash <(curl -s https://codecov.io/bash) -t $CODE_COV_TOKEN
+
+publish_task:
+  only_if: $CIRRUS_BRANCH == 'master'
+  script: cd doc && deploy.sh

.gitignore

@@ -9,7 +9,6 @@
 .history
 .svn/
 coverage/
-docs/node_modules/
 
 # IntelliJ related
 *.iml
@@ -30,6 +29,7 @@ docs/node_modules/
 .pub-cache/
 .pub/
 build/
+pubspec.lock
 
 # Android related
 **/android/**/gradle-wrapper.jar
@@ -72,3 +72,7 @@ build/
 !**/ios/**/default.pbxuser
 !**/ios/**/default.perspectivev3
 !/packages/flutter_tools/test/data/dart_dependencies_test/**/.packages
+
+# Vuepress related
+doc/.vuepress/dist/
+doc/node_modules/

CHANGELOG.md

@@ -1,5 +1,5 @@
-## [v0.0.1]
+## [v0.1.0]
 
 Initial Release
 
-[v0.0.1]: https://github.com/flrx/validator/tag/v0.0.1
+[v0.1.0]: https://github.com/flrx/validator/tag/v0.1.0

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when
+an individual is representing the project or its community in public spaces.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event. Representation of
+a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [[email protected]]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

README.md

@@ -2,20 +2,28 @@
 
 Validator on Steroids
 
+![Pub](https://img.shields.io/pub/v/flrx_validator)
 [![Build Status](https://api.cirrus-ci.com/github/flrx/validator.svg)](https://cirrus-ci.com/github/flrx/validator)
 [![codecov](https://codecov.io/gh/flrx/validator/branch/master/graph/badge.svg)](https://codecov.io/gh/flrx/validator)
+![GitHub](https://img.shields.io/github/license/flrx/validator)
 
 ## Installation
 
 Add the following to your `pubspec.yaml` file
 
 ```yaml
 dependencies:
-  flrx_validator: ^0.0.1
+  flrx_validator: ^0.1.0
 ```
 
 ## Usage
 
+### Documentation
+
+For more info on Flrx Validator and Rules you can see the [**documentation**](https://flrx.github.io/validator). 
+
+### Example
+
 ```dart
 import 'package:flrx_validator/validator.dart';
 import 'package:flrx_validator/rules/email_rule.dart';

docs/.vuepress/config.js → doc/.vuepress/config.js

@@ -3,20 +3,20 @@ module.exports = {
   description: "Validator on Steroids",
   base: "/validator/",
   themeConfig: {
+    displayAllHeaders: true, // Default: false,
     sidebar: ["/", "/validator", "/rule"],
     nav: [
       {
         text: "Changelog",
         link: "https://github.com/flrx/validator/blob/master/CHANGELOG.md"
       },
-      { text: "Github", link: "https://github.com/flrx/validator" }
-    ]
+    ],
+    /* Repository Config */
+    repo: "flrx/validator",
+    repoLabel: "Github",
+    docsDir: "doc",
+    docsBranch: "master",
+    editLinks: true,
+    editLinkText: "Help us improve this page!"
   },
-  repo: "flrx/validator",
-  repoLabel: "Contribute!",
-  docsRepo: "vuejs/vuepress",
-  docsDir: "docs",
-  docsBranch: "master",
-  editLinks: true,
-  editLinkText: "Help us improve this page!"
 };

docs/README.md → doc/README.md

@@ -1,13 +1,8 @@
----
-prev: false
-next: "./validator"
----
-
 # Introduction
 
 ## What is Flrx validator?
 
-It is a fluent API based form field validator for flutter, that promotes code reuse. It is highly extensible, modular and testable.
+It is a fluent API based FormField validator for flutter, that promotes code reuse. It is highly extensible, modular and testable.
 
 It is as simple as doing the following:
 
@@ -32,5 +27,5 @@ Add the following to your `pubspec.yaml` file:
 
 ```yaml
 dependencies:
-  flrx_validator: ^0.0.1
+  flrx_validator: ^0.1.0
 ```

docs/deploy.sh → doc/deploy.sh

@@ -16,10 +16,6 @@ git init
 git add -A
 git commit -m 'deploy'
 
-# if you are deploying to https://<USERNAME>.github.io
-# git push -f [email protected]:<USERNAME>/<USERNAME>.github.io.git master
-
-# if you are deploying to https://<USERNAME>.github.io/<REPO>
-# git push -f [email protected]:<USERNAME>/<REPO>.git master:gh-pages
+git push -f [email protected]:flrx/validator.git master:gh-pages
 
 cd -

docs/rule.md → doc/rule.md

@@ -1,8 +1,3 @@
----
-prev: "/validator"
-next: false
----
-
 # Rule
 
 [[toc]]
@@ -133,7 +128,7 @@ The built-in rules are not an exhaustive list of rules that can be possible. Hen
 
 The custom validation rule can be written this way:
 
-<<< @/custom_rule.dart
+<<< @/code/custom_rule.dart
 
 ## Custom Validation Message
 
@@ -157,4 +152,4 @@ Email is needed for creating an account
 
 All rules can take `transformMessage` function as well just like the `Validator`.
 
-You can refer [Validator.transformMessage](./Validator.html#transforming-the-message) for more Info.
+You can refer [**`Validator.transformMessage()`**](./validator.html#transforming-the-message) for more Info.

docs/validator.md → doc/validator.md

@@ -1,8 +1,3 @@
----
-prev: "/"
-next: "./rule"
----
-
 # Validator
 
 [[toc]]
@@ -15,9 +10,58 @@ The `Validator` takes a List of `Rule`. The value supplied to the
 `Validator` is supplied to the `Rule`s in the order they were registered.
 The error message of the first `Rule` that fails is returned back. If all the `Rule`s pass, then null is returned to the `FormField`.
 
+## Running the Validator
+
+There are two ways to run the validator.
+
+### Via `build()`
+
+The `Validator`'s `build()` method is useful if you want to add validation to a `FormField` Widget.
+
+```dart
+TextFormField(validator: Validator<String>().build())
+```
+
+
+### Via `validate()`
+
+The `Validator`'s `validate()` method is useful if you want to validate a value outside a `FormField`.
+For example, Flutter does not have any Cupertino FormField Widgets. For such cases you can perform validation like this:
+
+```dart
+
+  @override
+  Widget build(BuildContext context) {
+  
+    ...  
+        CupertinoTextField(controller: _textEditingController),
+        Text(emailValidationMessage),
+    ...
+  
+  }
+      
+  void onFormSubmitPressed() {
+    String value = _textEditingController.text;
+    setState(() {
+      emailValidationMessage = Validator<String>().validate(value) ?? '';
+      });
+  }
+  
+  ...
+
+}
+```
+
+You can see the full example [here](https://github.com/flrx/validator/blob/master/example/lib/cupertino_form.dart).
+
+::: warning
+Although for simple forms this may seem like a good idea, this could quickly go out of hand.
+You might want to use a Custom [FormField](https://api.flutter.dev/flutter/widgets/FormField-class.html) Widget instead.
+:::
+
 ## Adding Rules
 
-The `Validator` takes `Rule`s againt which the value is validated. You can add `Rule`s to the validator in the following ways
+The `Validator` takes `Rule`s against which the value is validated. You can add `Rule`s to the validator in the following ways
 
 ### Via `add()`
 
@@ -65,6 +109,7 @@ TextFormField(
     validator: Validator<String>(entityName: 'Password')
         .add(MinLengthRule(6))
         .build()
+)
 ```
 
 will produce a validation message like:
@@ -77,7 +122,7 @@ Password should be more than 6 characters
 
 `Validator` also accepts a function which can be used to transform the message that is returned after the validation of the input.
 
-`transformMessage` function can be used for cases like localization amongst others.
+`transformMessage` function can be used for cases like localization among others.
 
 By default, `transformMessage` replaces the `keys` in the `message` by the corresponding `values` which are defined in the `params` map.