Item9407: Improve user experience when creating pages via HTML form

Co-worker had this code:

<form action="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/">
   <input type="hidden" name="onlywikiname"  value="on" />
   <input type="hidden" name="onlynewtopic"  value="on" />
   <input type="hidden" name="topicparent"   value="%TOPIC%"  />

   <input type="text" name="topic"  size="30" value=""  />

   <input type="submit" value="Create New Topic"/>
</form>

He was surprised when he submitted the form and received the error

The "WebHome" topic already exists.
Cannot create WebHome because it already exists.
Please go back in your browser and try a new name.

(He had not specified a topic name in the text box of the form, so topic= was submitted as null.)

Suggestions for a better user experience:

1. While it makes sense for WebHome to be the default topic for a view operation, this does not make as much sense for edit
2. Given that onlywikiname was specified as on one might expect an error; null string is not a WikiWord.
3. If topic= is sent in the URL but the value is null, an error should be thrown. The presence of the parameter implies something was meant.
4. At the very least, it would be handy to add a parameter, e.g. topicrequired, which could be set to on. This could be useful in other cases as well.

-- VickiBrown - 29 Jul 2010

In general the core does react just fine. However, the combination of circumstances makes the error message sound odd. So, a more intelligent error message for this would be nice. Only queystion is: does the core already have enuf information to trigger a different error message?

We have:

1. urlparam topic being empty
2. basetopic = webhome
3. script = edit or save

not sure if onlynewtopic and onlywikiname makes any difference

Does this suffice to trigger an "Error: no topic specified" instead of a "cant edit webhome"?

Maybe we also need to capture the fact that the core did fall back to webhome during initialization of the Foswiki and Request object.

-- MichaelDaum - 29 Jul 2010

Defaulting to WebHome is a real problem. I have had some wiki apps malfunction and trash the WebHome a few times. I think this behaviour was changed slightly in trunk? I seem to recall somebody working on it...

-- PaulHarvey - 30 Jul 2010

I see similar behavior on foswiki 1.0.9. I created a test page on trunk (http://trunk.foswiki.org/Sandbox/TestTopic8) to determine if the problem is in trunk as well. It looks like it is.

-- DeanSpicer - 13 Aug 2010

An enhancement would be an additional parameter like onlyvalidtopicname that would show an appropriate error message if no topic name is passed.

But that would be a hack. A better approach is to have form validation in the core.

FormPlugin adds an extra hidden field for each validated field. For field Name (that should contain a string):

<input type="hidden" name="FP_validate_Name" value="Name=s">

If implemented in core this could be made less verbose/more self explanatory:

<input type="hidden" name="validate_topic" value="nonempty" />

-- ArthurClemens - 13 Aug 2010

Inline form validation is now offered by JQueryPlugin plugin validate.

-- ArthurClemens - 17 Mar 2011

that seems like overkill (the need to use JQueryPlugin). Also, sadly, where I work,. we can't use JQuery (not your problem of course). We're a YUI shop.

-- VickiBrown - 18 Mar 2011

What is left of this bug report is something like "don't fall back to WebHome under certain circumstances". These are not really 100% clearly defined as far as I see. Note that for example a REST script won't have a topic parameter either as some don't need it. Yet still the core requires it to be executed at a certain location in the wiki in terms of web and topic.

I think this all is better discussed and decided upon in a feature proposal that clearly outlines available solutions.

-- MichaelDaum - 07 Jan 2015

Commenting is disabled while not logged in