Item9407: Improve user experience when creating pages via HTML form
Current State: Proposal Required
Released In: n/a
Target Release: n/a
Co-worker had this code:
<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"/>
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:
- While it makes sense for
WebHome to be the default topic for a
view operation, this does not make as much sense for
- Given that
onlywikiname was specified as
on one might expect an error; null string is not a WikiWord.
- 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.
- 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.
- 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?
- urlparam topic being empty
- basetopic = webhome
- 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.
- 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...
- 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.
- 13 Aug 2010
An enhancement would be an additional parameter like
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.
adds an extra hidden field for each validated field. For field
(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" />
- 13 Aug 2010
Inline form validation is now offered by JQueryPlugin plugin
- 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.
- 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.
- 07 Jan 2015