Feature Proposal: AutoViewTemplatePlugin standardises the name of the skin page used for showing a topic with a form. We should merge it to core and install on FW.org

Motivation

Customising screens that use forms is very useful.

Implementing these in a standard way should be encouraged.

This is a lightweight plugin that conforms with conventions already used by Foswiki.

Description and Documentation

Proposed description (copied over from AutoViewTemplatePlugin):

Foswiki automatically sets the VIEW_TEMPLATE and EDIT_TEMPLATE variables according to a corresponding form definition. So when you attach a form to a topic, foswiki will enable the corresponding view/edit template automatically.

Assuming a topic has a MyForm DataForm attached, it will be displayed using the view template MyView and editted using the MyEdit if they exist. The template name is derived by stripping off the suffix ...Form from the form name and appending ...View or ...Edit.

MyView and/or MyEdit has to be in the same web as the corresponding MyForm.

Examples

We could use this to:

• Show Tasks related to Extensions on the Extensions pages without repeating this code on the Extension page
• Show Change Password, Change Email address on the Users' home pages without having this code in their page
• Show a combined doc/support/bugs view for Extension pages without touching every extension txt file (see Item293)

Impact

WhatDoesItAffect:

Implementation

-- Contributors: MartinCleaver - 21 Nov 2008

Discussion

Yep.

-- MichaelDaum - 24 Nov 2008 - 12:50

Would be useful to show a combined doc/support/bugs view for Extension pages without touching every extension txt file. Current version on FW and in SVN is already moved to the Foswiki namespace. We need to move to Foswiki on foswiki.org prior to installation of this plugin.

-- OliverKrueger - 27 Dec 2008 - 03:43

The plugin is now installed on f.o.

-- OliverKrueger - 26 Jun 2009

This is an excellent idea, but I have a couple of questions relating to it's possible implementation in the core.

The "exist" mode is easy to understand, and easy to support. The "section" mode is more complex, and the documentation topic is unspecific as to what happens when:

• There are two or more sections in a topic, each of which is named viewtemplate/edittemplate
• The topic matches the exists rule but also has a section

There are no examples of usage of the two modes (these should be given in this topic).

In short I can support the merging of the exists mode as documented, but cannot support the section mode without significant improvements to the documentation.

-- CrawfordCurrie - 28 Jun 2009

I once discussed that with OliverKrueger and he admitted that "section" mode is not that useful as you could do the same otherwise - not sure if that still holds. So most probably we can reduce this feature request to "exist" mode only.

-- MichaelDaum - 28 Jun 2009

TBH, I never used the section mode myself. I implemented it at a time, when I was discovering Michaels Workbench concept. I thought, it would be useful to have a way to set a different view_template via a named section on the form definition topic.

Lets drop the section mode for the core.

-- OliverKrueger - 28 Jun 2009

Okey dokey. On that assumption, I'm no longer concerned.

-- CrawfordCurrie - 29 Jun 2009

This proposal was 14-day rule stopped by concern.

And we have now reached concensus.

Before we change the proposal to Accepted with reason Concensus Reached - I would like Oliver to alter the proposal text to the agreed compromise. Ie we need documentation of the exact feature that is desired to be merged to core.

-- KennethLavrsen - 03 Aug 2009

ping Oliver

-- KennethLavrsen - 04 Sep 2009

Is that ok, Kenneth?

If yes, shall I delay my checkin till the release of trunk?

-- OliverKrueger - 05 Sep 2009

Yes. Task described well now.

So I change it to accepted.

We could in principle add it to the standard MANIFEST so it gets included. If is causes trouble an extension is easy to remove again should the 1.1 be in trouble because of it.

Unlike core code features that are difficult to revert once integrated and other changes has followed.

I would not scream if you add it. But please implement the feature in the plugin first before adding the plugin to the core MANIFEST.

-- KennethLavrsen - 23 Sep 2009

I'd like to ask for more :/

first up, I'd like to have additional topic template 'bits' - essentially LISTVIEW_TEMPLATE and LISTEDIT_TEMPLATE to improve both the WebChanges and MailNotify outputs, and support things like the TasksContrib.

and I'd love to have these 4 settings be able to use topic SECTIONs.

I've found that defining all of a form in a single topic makes life much easier for fast development....

that way the ChangeProposalForm topic would also contain 4 sections - view_template, listview_template, edit_template, listedit_template.

Additionally - can we deprecate the really confusing The template name is derived by stripping off the suffix ? Many users get quite confused by the fact that there's a setting that points to a topic that does not exist, and then some magic occurs to make it load a totally different topic.

-- SvenDowideit - 06 Oct 2009

I just started using this plugin. It is a gem.

I actually found that the feature of being able to use the same view template for multiple forms is a nice feature.

I do not understand why people would not want this included.

The feature that just derives the view template name from the form name means that I cannot reuse a "!FormOnTopTemplate" for 2 or 3 forms. I have to duplicate the same view template for multiple forms.

I syntax of using a section is a bit odd and a simpler and more intuitive one could be better. I had to read the documentation 10 times and try to see if I understood. But I like the idea that I can add something to a form definition topic and this then can define view and/or edit templates. That is brilliant.

I agree with Sven that the auto-appending Template in general is a sick feature which is very confusing. I cannot unerstand why you cannot just write the direct name of the template. But that is a feature proposal on its own (deprecating but not removing the ...Template, and allow directly writing the template name also in a setting).

-- KennethLavrsen - 06 Oct 2009

Automatically deriving the view template from the form name is the most important invention of AutoViewTemplatePlugin. That's why it is called AutoViewTemplate. The section-based feature is not that useful if at all.

If you don't want automatic view and edit templates, then just set the VIEW_TEMPLATE and/or EDIT_TEMPLATE preference variable of that topic. That's the standard Foswiki feature.

All of my applications, i.e. those based on the WikiWorkbench paradigm, deriving the view and edit template from the form name. This must not be trashed.

Of course reusing the same view template automatically on different forms is not possible. In practice this use case occurs rarely. That's because a different form has got different properties to be displayed.

Template reuse is done on a different level. If you want to reuse templates then this is done using TMPL:INCLUDE. Normally you've got a TMPL:INCLUDE{view} at the top of a view template. If you'd like to reuse another template then change this to TMPL:INCLUDE{Applications.ClassificationApp.ClassifiedTopicView} , for example, and then override the predefined bits using TMPL:DEF.

About LISTVIEW_TEMPLATE etc. I am pretty sure the core is already powerful enuf that you don't need that. WebChanges, WebTopicList and WebSearch could all do without it by using a System.WebChangesViewTemplate, System.WebTopicListViewTemplate and System.WebSearchViewTemplate respectively. Within each of these view templates the TMPL structure does all of the rest. This touches the ugly REPEAT/SPLIT concept in search.tmpl being far too clumsy, but also attachtables.tmpl where a somewhat different approach has been taken.

Whatever.

The current AutoViewTemplatePlugin is definitely a gem as is . I'd rather not overload it with additional feature requests as part of its "blessing" process

-- MichaelDaum - 06 Oct 2009

I am not asking for extra features.

I am asking for not to remove the section feature.

It is very smart that I can define ONE template topic used in 2 or 3 different applications that uses 2 or 3 different forms.

It is useful to me. That is a fact!

The VIEW_TEMPLATE and EDIT_TEMPLATE settings have to be put in each and every topic. The smart thing with AutoViewTemplatePlugin is that the templates are automatically applied when you add the form.

Especially for existing applications where you already have 100s of topics. I added this plugin and by editing a few forms and defining one common FormAtTopTemplate I was able to change the way the application works without editing 100s of topics. Brilliant. Without the 'section' I could have done the same but I would have had to create 3 identical view template and maintain them. Now I can just use one. That is why I like the section feature also. I will for sure also use the default 'exist'. That will be my preferred when a view or edit template is unique to a single form.

I agree that the default should remain the current behaviour. Ie the 'exist' behaviour where template name is derived from form name.

But please support that we do not remove the section feature. Just because some of you do not use it does not mean the rest of us should not be able to. And it does not cost any pain for you that won't use it.

I have added the missing documentation now for the 'section' mode. Please let us keep both modes as they are.

-- KennethLavrsen - 06 Oct 2009

Alright alright, no worries.

I see your point of applying the same view on several models.

#Rulebased How about registering a template explicitly for a topic whose form or topic name matches a certain pattern? That way you could automatically overlay a view template on topics even though they have no form and without touching them at all.

Something in configure like:

$Foswiki::cfg{AutoViewTemplate}{ViewTemplateRules} = {
   'WebTopicList' => 'System.WebTopicListView',
   'Tasks.*' => 'Tasks.FunkyView',
   'Item.*' => 'Task.FunkyView'
};

For instance KinoSearchContrib could define a view template for WebSearch without touching it thus creating a completely new interface more appropriate for kinosearch (removing useless cruft).

-- MichaelDaum - 06 Oct 2009

That is an interesting feature Michael. And it deserves it's own feature proposal topic. It could be a good tool for the extensions developer that wants to influence presentation of standard topics without distributing alternative versions which later are in risk of getting overwritten when upgrading.

-- KennethLavrsen - 06 Oct 2009

For the kinosearch idea, we would also need UpgradeSafeCustomisationsOfSystemTopics to be implemented, which I would really like in 1.1.

-- AndrewJones - 06 Oct 2009

The above specs have been proposed at Rulebased View Templates.

-- MichaelDaum - 03 Nov 2009