You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in the works is a redux of the old cfwheels plugins site.
Overview
The directory lists cfwheels plugins (and possibly more in the future, such as boilerplate apps, modules) and provides a way of getting that data via JSON for use with CommandBox, or by browsing the site. Plugins are filterable by Category and Owner.
Each listing includes information automatically pulled from gitHub; Descriptions, readme, and releases/downloadable assets.
Assuming this all goes well, this could open the door for a cfwheels command line interface for CommandBox, allowing plugin installation, package installation, more automated testing, scaffolding etc.
A New Standard for plugins.
In order for plugins to be added to the directory, they must satisfy some basic requirements.
Your plugin needs to live in a public gitHub (http://github.com) repository.
This really is the minimum ‘standard’ which I propose new plugins should adopt.
Without a release (with an attached binary) it’s basically impossible to know what the definitive version of the plugin should be, as different repos have different standards (i.e, not using releases, or having src folders etc;)
Pros:
Quick to add a new plugin
Data is pulled in automatically except categories which are assigned on entry
Downloads are provided by github; we’re just providing the link. We can also get download figures from the API.
Updated readmes, descriptions and new releases can be auto pulled in.
Cons:
Some / a lot / of plugins may well require creating a release on their repos. We could however, fork them over if needed and do the release ourselves if the plugin is of suitable importance
Some data, such as compatible wheels versions, we can’t get from GitHub; we’d need to parse the actual plugin cfc to get the init() function, which isn’t really practical for all the usual reasons.
Progress:
Setup example new plugin repository style
Setup initial local test site / proof of concept
Deploy Alpha version for internal core team comments
Unit Tests
Deploy Beta version for public comments
Release
The text was updated successfully, but these errors were encountered:
Currently in the works is a redux of the old cfwheels plugins site.
Overview
The directory lists cfwheels plugins (and possibly more in the future, such as boilerplate apps, modules) and provides a way of getting that data via JSON for use with CommandBox, or by browsing the site. Plugins are filterable by Category and Owner.
Each listing includes information automatically pulled from gitHub; Descriptions, readme, and releases/downloadable assets.
Assuming this all goes well, this could open the door for a cfwheels command line interface for CommandBox, allowing plugin installation, package installation, more automated testing, scaffolding etc.
A New Standard for plugins.
In order for plugins to be added to the directory, they must satisfy some basic requirements.
See an example of a 'properly' setup repository: https://github.com/neokoenig/cfwheels-plugin-example
This really is the minimum ‘standard’ which I propose new plugins should adopt.
Without a release (with an attached binary) it’s basically impossible to know what the definitive version of the plugin should be, as different repos have different standards (i.e, not using releases, or having
src
folders etc;)Pros:
Cons:
Progress:
The text was updated successfully, but these errors were encountered: