Feature Proposal: Provide the means to manage Foswiki applications

Motivation

Wiki Applications are the reason that structured data makes such a difference in Foswiki. However, while Foswiki provides features and structure and documentation for structured data, it leaves the construction, management and documentation of Applications to end users. The result is a plethora of different approaches to managing applications, and only mastery by the longest-standing members of the community.

Description and Documentation

• Provide a standard place to keep Application topics
• Allow multiple data sets for the same Applications
• Provide the means to deploy and/or upgrade an Application to target webs
• etc.

We seem to have

1. http://foswiki.org/Extensions/FoswikiApplicationsContrib (unclear what this is - just some examples, not management)
2. http://foswiki.org/Development/WikiWorkbenchContrib (only in SVN)
   • Read FirstSteps to get an idea

These contribs may address some of these issues, but the feature should become part of the platform.

Examples

Impact

WhatDoesItAffect:

Implementation

-- Contributors: MartinCleaver - 28 Jan 2011

Discussion

Hello Martin,

I think what you're doing is great. We're maybe not getting as much feedback on this issue as we'd like because the "old timers" around here are so used to doing things their own way.

I'd like to get some time to help address this later when I'm not so busy at work, but essentially I don't agree with WikiWorkBench's use of a single form - in my own work I have many separate forms which users create. But even that's not good enough, because we are stuck with single form-at-a-time (although the query language can cope with multiple forms, Foswiki::Form - the UI part - cannot; also it's unlcear how the meta schema should do multiple forms).

Another major point is that I don't agree with using AutoTemplatePlugin in the way it does, name-based rules to load a template to "fake" a topic. I'd very much rather application topics be derived from someplace, and have them magically "appear" in the web like a real topic. This sounds like exactly the same thing as what AutoTemplatePlugin does, however what I want has an important difference: The "application topics" should magically exist in a target web as if they really were there; they would show up in searches, you would be able to tag them, comment on them... If the user edits & saves the topic, that really does create the new topic from the application original (and thereafter if a topic of the same name exists in the target web, Foswiki will render/manipulate that instead of the application topic).

I haven't quite thought this through, so I'm not sure if what I'm saying is a good idea or even makes coherence sense. I'm interested to see where this goes. Sven has told me that what I'm talking about would be possible with some modifications to the Store (or maybe just a plugin that uses the new Store listener thingy that Crawford built).

-- PaulHarvey - 30 Jan 2011

The multiple form problem is why Micha uses the single form approach. Im not sure yet, if I like using checkboxes/lists to type a topic instead of creating a dedicated form for that type. Maybe I'm just used to the traditional way. Regarding the name-based templating via AutoTemplatePlugin: This is very useful and I dont wanna miss that feature. Paul, when you speak of "derive", do you mean "copied at some point of time"? If yes, the AutoTemplate way is much better in case you want to make changes on existing data.

-- OliverKrueger - 31 Jan 2011

Happily, most of the data topics on my wiki work fine with just one form attached. Generally if I need more than one form, it's time to split the datum into more than one topic (especially for one-many type relationships). But I fully understand that many (most?) DataForms users would prefer multiple forms on one topic.

So, when I say "derive", I don't mean make a copy. I mean something closer to symbolic link. I haven't decided what I would like to happen when a user tries to modify a "linked" topic: edit the original, or create a copy.

I always do something like this:

• /Some/Application/Code/Topic - has the actual app "code"
• /Target/Web/Topic - just an INCLUDE -

  %INCLUDE{"Some/Application.%TOPIC%" option1="1" option2="2"}%

I'd hate for users to lose the ability to annotate, re-parent, comment and otherwise play with their own version of the "deployed" topic.

Here's what I'm thinking:

• /Some/Application/Code/Topic - contains the "code"
• /Some/Application/Deploy/Topic - contains just the INCLUDE
• /Target/Web/Topic - doesn't exist, but we somehow tell Foswiki to pretend that it does, using /Some/Application/Deploy/Topic

I have previously mentioned the idea of "Phantom webs" in other discussions, I guess what I'm talking about here is phantom topics.

My initial thoughts were that you'd have a search path, like we do for SKIN, but for "phantom topics". If a topic doesn't exist, then search a series of "phantom webs" for the first one that contains it, Eg. let's pretend this is implemented, we wouldn't need to copy so many Web* topics - in fact a new web only needs WebPreferences. Let's see:

• Set PHANTOMWEBS = System/SolrPlugin, System

Then when you request the missing topic WebSearch, it first tries System/SolrPlugin.WebSearch followed by System.WebSearch

I can appreciate that for some circumstances you don't want the users to be able to modify these "phantom" topics; so protect them with an ACL accordingly.

I'm sorry, but AutoTemplatePlugin makes "template" topics second-class citizens.

-- PaulHarvey - 31 Jan 2011

I'd really like to see how far phantom topics/webs could help here. That's a nice idea.

Not sure I understand you, Paul, saying template topics are second-class citizens. View and edit templates is one of the most useful features of Foswiki.

Meanwhile here's a discussion about TopicTypes, DataForms and Alfresco's way to do it: http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2011-01-26,Wed&sel=501#l497

Baseline: we all agree that a single DataForm has got limitations. While you can use TopicTypes to deal with the system as is to simulate multiple DataForms, real multiple DataForms attached to a single topic would be much better. The actual bottleneck in this system is the way a DataForm definition is fetched for a single topic. It does so by looking up a META:FORM field that corresponds to a single physical topic that holds a foswiki table which finally defines which formfields are part of this form. Instead, we should load the DataForm definition in a more dynamic or virtualized way, either by some inheritance or mix-in semantic. Inspired by Alfresco this would mean that the core creats a Foswiki::Form object not by parsing a single physical object, but by creating one on the fly in memory by gathering all aspects the user decided to use on the current topic. Each aspect is a set of formfield definition similar to our DataForm definitions we have right now. All currently selected aspects could be saved in a META:ASPECTS preference list value thus replacing the META:FORM thingy.

So these kind of dynamic DataForms would be way to overcome one of the most criticized shortcoming of Foswiki's way of wiki applications.

-- MichaelDaum - 31 Jan 2011

By "second class citizen" I mean of topics. They're not real, it's just a template hack. They cannot have a life beyond what the template coder gives them. They aren't touchable by end-users, Eg. for commenting or tagging.

Dynamic DataForms, this sounds cool.

-- PaulHarvey - 31 Jan 2011

Instead of parsing a foswiki table, an aspect could even be implemented by a plugin handler returning a partial form definition to be merged in.

Right, you can't comment or tag a template stored in the templates directory of foswiki. But you can of course comment or tag templates as soon as they are stored in some topic, which is quite common for wiki apps to do. The big advantage of writing wiki apps completely in wiki topics is that you can do all the normal wiki collaboration things that you do with topics normally.

Maybe I still don't fully get your above comments about templates and AutoTemplatePlugin in specific.

-- MichaelDaum - 31 Jan 2011

Templates are a very powerful part of Foswiki, however they are also one of the most frustrating and difficult-to-learn. I would like "phantom" topics to appear exactly as if they were real topics; in searches, navigation, with history and so on.

If we can make "phantom" topics no more difficult than INCLUDEs - this would open up wiki-app'ing to many more people. I really can't stress how much I value power users building their own stuff. It empowers them in a way they can't get on other collaboration/database platforms.

If adding an application to a web was as simple as adding to a list of items in a preference setting, this could be a nice way to easily deploy apps in a way that everybody can easily understand.

Additionally, autoview wouldn't allow a target web to inherit DataForms and other topics, etc.

-- PaulHarvey - 31 Jan 2011