create new tag
, view all tags

Form Definition for Add-On/Plugins/Skin Packages

Note: This web has two forms: This PackageForm for Add-On/Plugin/Skin packages, and WebForm for all other types of topics. To switch between forms, edit a topic and press the [ Change ] button.

Name: Type: Size: Values: Tooltip message:
TopicClassification select 1 Select one..., PluginPackage, AddOnPackage, SkinPackage, ContribPackage, ObsoletePluginPackage, ObsoleteAddOnPackage, ObsoleteSkinPackage, ObsoleteContribPackage, IncompletePackage Classify a topic
TestedOnTWiki checkbox 4   Tested on what TWiki version
TestedOnOS checkbox+button 4 AnyOS, AnyUnix, OsHPUX, OsLinux, OsSolaris, OsMacOsX, OtherUnix, AnyWin, OsWinNT, OsWin2K, OsWin9598ME, OsWinXP Tested on what OS
ShouldRunOnOS checkbox+button 4 AnyOS, AnyUnix, OsHPUX, OsLinux, OsSolaris, OsMacOsX, OtherUnix, AnyWin, OsWinNT, OsWin2K, OsWin9598ME, OsWinXP Not tested, but should run on OS
InstalledOnTWikiOrg radio 2 No, Yes Installed on this server for testing
DemoUrl text 60 http:// A URL where this package can be seen in action
DevelopedInSVN radio 2 No, Yes Package is checked in to the subversion repository
ModificationPolicy radio 3 PleaseFeelFreeToModify, ContactAuthorFirst What the author wants you to do about making modifications to this package
RelatedTopics text 60   Links to categories and related topics

-- PeterThoeny - 19 Apr 2003

I've added a demo url to the above as it is something that people often ask when they read a plugin. There is no obligation to provide one but one helps take-up and therefore the feedback/improvement cycle.

-- MartinCleaver - 28 Apr 2003

I've added the author field after having to trawl through multiple topics looking for a simple piece of info.

-- MartinCleaver - 17 May 2003

I appreciate the initiative but I removed it since we would duplicate information. The author is already defined in the info table of the Add-on/Plugin/Skin topic. Example for Plugin:

Plugin Author: TWiki:Main/guest
Plugin Version: 17 May 2003

Content that is specific to the Plugins repository should go into this form; content that is specific to the Add-on/Plugin/Skin description should go into the topic since it gets distributed with the package. E.g. in each TWiki site we would like to know who the author of a Skin is.

Therefore, it is better to update existing Add-on/Plugin/Skin topics with the latest template format as defined in AddOnPackageHowTo, PluginPackageHowTo, SkinPackageHowTo, respectively.

-- PeterThoeny - 17 May 2003

Fair point but I note that many of the Skins actually do not have said (supposedly mandatory) info table listed. Given that such information should be mandatory for topics of a certain type, would it not be better to move the info table into the meta data?

-- MartinCleaver - 17 May 2003

And duplicate the author info in 72 Plugins that already have the author in the info table? The PackageForm form is shared among Add-on/Plugin/Skin package topics. The author should go into the description not into repository data. Better to update the few skin topics that do not have the info table.

-- PeterThoeny - 17 May 2003

I argue that it was mandatory data in the first place, and so is best enforced using the forms mechanism. In contrast, can you explain to me what justification you give for The author should go into the description not into repository data.?

-- MartinCleaver - 17 May 2003

Added another field to flag all those plugins that leave files in (e.g.) /bin.

-- MartinCleaver - 6 June 2003

Thanks for the initiative, but I am not sure if the latest FilesOutsidePluginDir addition makes sense since it duplicates the information already in the "Content" table located in the Installation section. If that table is missing in an Add-On/Plugin/Skin it should be added. Also, some Add-Ons like the DiscussionForumAddOn only have topic files, no libs. For now I reverted the change.

-- PeterThoeny - 07 Jun 2003

Fair enough... but. Again, if the "Content" table was mandatory data in the first place it would be best handled by the form. Even PollPlugin (written by a CoreTeam member) does not have the content table.

I guess we need a Plugin Describer Plugin that can pull this information out from CVS and a PluginsMaster to check for standards.

-- MartinCleaver - 09 June 2003

Again, the form data does not get installed when you install an Add-on/Plugin/Skin, only the topic content. When an author creates a package topic the standard way she gets the correct template to fill out.

-- PeterThoeny - 09 Jun 2003

What you say is fine:

  1. IF people follow the exact route you expect them to AND if you have a way of detecting when they don't AND have a process of correcting when they haven't. But they don't, we haven't and without a TWikiExtensionsMaster I doubt that we ever will have. (Unless you want to spend more time on trivial administrative issues - your time is too important for that).
  2. IF you don't want to add more information required by each TWikiExtension. (So you can forsee all our future requirements, that limits TWiki's innovation to what YOU think at the start, we should be leveraging everyone's efforts)
  3. IF you don't want to do any more processing/cross-referencing with the data given in those tables (e.g. how many of the plugins say that they require a CPAN module?).

TWikiForms are a great mechanism, the template system is much less powerful. For the sake of managing the complexity of this place I urge you to reconsider.

-- MartinCleaver - 09 June 2003

As per PerformanceWithManyPlugins, made performance testing a requirement.

On a separate note, Peter, would you care to comment on the last issues I raised?

-- MartinCleaver - 01 Aug 2003

Refactored out HowToDocumentPluginPerformance. Once decided we can enhance the PackageForm or the NewPluginTemplate.

-- PeterThoeny - 01 Aug 2003

Removed AuthorHasNotSpecified. The default is now PleaseFeelFreeToModify.

-- CrawfordCurrie - 28 Apr 2004

Reference TestedOnTWiki as discussed on PluginsTestedStatus to obtain latest status. Plugin authors are encouraged to verify what actual beta version, if any, they comply with.

-- ThomasWeigert - 16 May 2004

I want to add a row:

PluginMaintainer select 1   Which registered user maintains this plugin

But I can't get the lookup to work. Is this worth having?

-- MartinCleaver - 03 Oct 2004

How about renaming TestedOnTWiki to "WorksWithTWiki" and have another "DoesntWorkWithTWiki"?

This would allow us to say that ImageGalleryPlugin only works with Dakar but ThreadedDiscussionPlugin only works with Cairo.

Interestingly both "WorksWithTWiki" and "DoesntWorkWithTWiki" would need populating from the same list of TWiki versions.

-- MartinCleaver - 25 Apr 2005

There are huge amount of TWiki Plugins (17x) and I found I constantly scan the PluginPackage to find something fit.

The long-term solution maybe rely on Categorization when submitting PackageForm from plugin author. The ZenderChenSandbox is a demo of short-term solution that categorized mannully for quick reference.

-- ZenderChen - 09 Aug 2005

Zender, you are totally right.

Thanks for your help.

Would you like to take charge of PluginsNeedCategorizing ?

-- MartinCleaver - 09 Aug 2005

Martin, adding categories is a good idea. Please wait with mass-updates. I have some additional ideas to make a good taxonomy for the Plugins web.

Temporarily parked form field:

| ExtensionCategories | checkbox+button | 4 | | |

-- PeterThoeny - 11 Aug 2005

I'll leave you to drive this initiative, Peter.

-- MartinCleaver - 11 Aug 2005

Peter, you said in SwitchingGears that this was a priority for you. Do you plan to share your additional ideas any time soon? How much longer should we wait? Zender cannot proceed until we reenable this field.

-- MartinCleaver - 12 Sep 2005

I will address the taxonomy of the plugins web soon. Just a lttl prssd nw. I do not understand why Zender cannot proceed in the mean time.

-- PeterThoeny - 14 Sep 2005

As I see it the next step is to go ahead and assign the ExtensionCategories to the extensions according to the taxonomy we arrived at in PluginsNeedCategorizing. i.e. add back the category field and edit each of the 150 topics to fit. In the process new categories will doubtless be arrived at, but this is a learning-by-doing process. There is no point maintaining a separate list: we already have two of those, the one on PluginsNeedCategorizing and the one on ZenderChenSandbox

If you can see something for Zender to do in the meantime then please advise.

Do you want this complete by WikiSym?

-- MartinCleaver - 14 Sep 2005

I added a new RelatedTopics form field. This should be used to add existing categories and links to related topics.

I also removed the deprecated form fields.

-- PeterThoeny - 14 Feb 2006

I removed the ForkIfForPriorRelease from the ModificationPolicy for the following reasons:

  • The ForkIfForPriorRelease opinion/wish is already covered by the ContactAuthorFirst, e.g. the author should be contacted first before code is updated (the author thus can intervene if the contributor wants to change the code to be Cairo/Dakar compatible)
  • It sends a developer centric message to the TWikiCommunity
  • New Plugins are created typically just for Dakar, e.g. HandlingCairoDakarPluginDifferences does not apply

-- PeterThoeny - 23 Apr 2006

How about a SupercedesExtension field? The intention would to help an author state that they intend people to not use this plugin as another is better. This would be a precursor to a plugin being designated as Obsolete.

-- MartinCleaver - 31 May 2006

From the usage pattern, wouldn't a "superceded by" be more useful? When I look at an extension I am not so much interested in learning what other extension it supercedes, I am more interested to learn if there are better alternatives than the one I am looking at.

For this I'd rather keep it simple:

  • Keep as active package as long as it usable, but describe at the top that XyzPlugin is a better alternative.
  • Mark as obsolete once no longer maintained and the other package(s) cover the functionality.

-- PeterThoeny - 31 May 2006

I think the CompliesWithPolicy needs some discussions before/if we take this into the form. For now I removed from the form (| CompliesWithPolicy | checkbox | 3 | Yes, no, not applicable |). Please discuss in CompliesWithPolicy.

-- PeterThoeny - 06 Jul 2006

Arthur, why is the "Download URL" form field necessary? It is implicitly <topic>.zip. All the reports in the Plugins web assume that. If we change that we need to fix all forms and all reports. For now I moved the form field out of the form definition table to here:

| Download URL | text | 80 | http://www.twiki.org/p/pub/Plugins/PackageForm/PackageForm.tgz | Direct download link to tgz file |

-- PeterThoeny - 02 Feb 2008

The current urls use viewfile. That does not work with wget. Now if you want to install an extension to a webserver, you must download the package using a browser, and copy it to the server. Whereas with a direct pub link you can copy that link and use wget thelink to download it.

Why need all forms and reports to be fixed if one line is added to the form table?

-- ArthurClemens - 02 Feb 2008

For example, these reports already assume the direct pub URL link:

If we change the implicitly %PUBURL%/Plugins/<package>/<package>.zip link we need to add the Download URL to all existing packages and fix all reports. For simplicity I suggest to keep the implicit link rule. That way you can also use wget.

-- PeterThoeny - 02 Feb 2008

zip is fine with me. It is just that on the extension page no direct pub download link is offfered.

-- ArthurClemens - 02 Feb 2008

Edit | Attach | Watch | Print version | History: r58 < r57 < r56 < r55 < r54 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r58 - 2012-10-25 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.