Feature Proposal: Too many forms make head hurt

Motivation

Currently there are two different forms used with extensions - the table at the end of the extension description, and the PackageForm that exists on fw.o. That's one too many.

Description and Documentation

We really want to have just one form in the extension that is shipped in the System web - call it PackageForm. This form can be extended in the Extensions web of f.o to add the site-specific fields we use.

The advantage of using a form is it makes searching extensions much easier (as query searching can be used) and imposes a format.

Implementation

I propose that we create a PackageForm in the (shipped) System web as follows:

| *Name:* | *Type:* | *Size:* | *Values:* | *Tooltip message:* |
| Author | text | 60 | | |
| Version | text | 60 | | Numerical version number e.g. 1.2 |
| Release | text | 60 | | Release identifier (usually the date) |
| Copyright | text | 60 | | e.g. 2015, The Artist, All Rights Reserved |
| License | text | 60 | | e.g GPL ([[http://www.gnu.org/copyleft/gpl.html][GNU General Public License]]) |
| Latest Change | text | 60 | | Describe the most important changes of the latest release | 
| Home | text | 60 | | e.g. http://foswiki.org/Extensions/%TOPIC% |
| Support | text | 60 | | e.g. http://foswiki.org/Support/%TOPIC% |

1. The definition of the Extensions.PackageForm needs to be extended with the fields above.
2. BuildContrib needs to be modified so that when .txt does not contain a PackageForm, then one will be generated automatically from the nasty table, and the nasty table removed during the build process. (The attached patch does this, only leaving the table rows it can't recognise)
3. Convert .txt's of core extensions to use the new System.PackageForm

-- Contributors: CrawfordCurrie - 26 Feb 2015

Discussion

+1

It would be great to automate ExtensionNews. I'd extend above form with a Latest Change formfield.

The rest of the Change History should actually be part of the wiki text.

We need a script to convert all existing extension topics to the new format.

-- MichaelDaum - 26 Feb 2015

Strictly speaking we don't need a mass conversion, as my BuildContrib mod extracts the fields from the existing form. However I think all the core extensions should be converted to a form.

I suspect LatestChange would be hard to automate, because it would require some smart (ish) parsing of the changes table in existing tabular forms. However there's no reason not to extend Extensions.<nop?PackageForm with that field.

-- CrawfordCurrie - 26 Feb 2015

I suggest we also include a repository or released from field of some sort that points to the source repository. The Core extensions would point to github foswiki/distro, others point to github foswiki/<extension>. But future extensions might be github <someauthor>/<extension> This would allow future extensions to be sourced from other locations than the foswiki project account on github.

-- GeorgeClark - 26 Feb 2015

Good idea; but out of scope for this proposal (I'm only proposing to reorganise existing data, not to add more)

-- CrawfordCurrie - 26 Feb 2015

Adding a Repository formfield seems totally sensible. We could even pre-populate it as George outlined. People could then change it to whatever they like.

-- MichaelDaum - 26 Feb 2015

We could have star rating with SocialFormfieldsPlugin.

-- MichaelDaum - 27 Feb 2015

We could, and that's another great idea, however it is also out of the scope of this proposal. TBH I'm wondering if raising a feature request was the right way to go, perhaps I should just have done this as an admin task.

-- CrawfordCurrie - 27 Feb 2015

Commenting is disabled while not logged in