WWW-WuFoo 0.002
Kwalitee Issues
- has_changelog
-
Add a Changelog (best named 'Changes') to the distribution. It should list at least major changes implemented in newer versions.
- has_tests
-
Add tests!
- no_pod_errors
-
Remove the POD errors. You can check for POD errors automatically by including Test::Pod to your test suite.
Error: WWW-WuFoo-0.002/lib/WWW/WuFoo/Comment.pm -- Around line 25: Non-ASCII character seen before =encoding in 'youâve'. Assuming UTF-8 WWW-WuFoo-0.002/lib/WWW/WuFoo/Entry.pm -- Around line 24: Non-ASCII character seen before =encoding in 'weâll'. Assuming UTF-8 WWW-WuFoo-0.002/lib/WWW/WuFoo/Login.pm -- Around line 24: Non-ASCII character seen before =encoding in 'userâs'. Assuming UTF-8 WWW-WuFoo-0.002/lib/WWW/WuFoo/WebHook.pm -- Around line 17: Non-ASCII character seen before =encoding in 'userâs'. Assuming UTF-8
- meta_yml_declares_perl_version
-
If you are using Build.PL define the {requires}{perl} = VERSION field. If you are using MakeMaker (Makefile.PL) you should upgrade ExtUtils::MakeMaker to 6.48 and use MIN_PERL_VERSION parameter. Perl::MinimumVersion can help you determine which version of Perl your module needs.
- has_meta_json
-
Add a META.json to the distribution. Your buildtool should be able to autogenerate it.
- has_tests_in_t_dir
-
Add tests or move tests.pl to the t/ directory!
- meta_yml_has_provides
-
Add all modules contained in this distribution to the META.yml field 'provides'. Module::Build or Dist::Zilla::Plugin::MetaProvides do this automatically for you.
- meta_yml_has_repository_resource
-
Add a 'repository' resource to the META.yml via 'meta_add' accessor (for Module::Build) or META_ADD parameter (for ExtUtils::MakeMaker).
Modules
Name | Abstract | Version | View |
---|---|---|---|
WWW::WuFoo | Interface to WuFoo.com's online forms | 0.002 | metacpan |
WWW::WuFoo::Comment | The Comments API is used to gather details about comments youâve made on forms you have permission to view. | metacpan | |
WWW::WuFoo::Entry | The Entries API is used to gather the data that users have submitted to your form. In this section weâll describe the hierarchy of the entries element as well as describe the syntax for filtering this data. | metacpan | |
WWW::WuFoo::Field | The Fields API describes the hierarchy of your data. At the heart of this API is the listing of FieldId values. Each FieldId corresponds to a value in the Entries API. | metacpan | |
WWW::WuFoo::Form | The Forms API is used to gather details about the forms you have permission to access. This API can be used to create a list of all forms belonging to a user and dynamically generate a form embed snippet to use in your application. | metacpan | |
WWW::WuFoo::Login | The Login API is designed to allow approved partners access to userâs API keys given an email, password and (optionally) a subdomain. In other words, this API gives you the ability to gather the API key for a user without them having to visit Wufoo. This keeps your user engaged in your process because they donât have to leave your site. | metacpan | |
WWW::WuFoo::Report | The Reports API is used to gather details about the reports you have permission to view. | metacpan | |
WWW::WuFoo::User | The Users API is used to gather details about the users you have defined through User Management. | metacpan | |
WWW::WuFoo::WebHook | The WebHooks API is designed to help you inject a web hook into your userâs form. We believe this API will help reduce the friction your users experience integrating with your site. Letâs compare the steps your user would have to go through to set up a traditional site-to-site web hook integration to a Web Hook set up through the API. | metacpan | |
WWW::WuFoo::Widget | The Widgetes API is used to gather details about the widgets you have permission to view. Used in combination with the reports you could easily build a tool to view widgets for a given report. | metacpan |