Which aspects of this design do people want first?
leiger wrote on 11 Nov 2009 12:44
This is a major feature, consisting of many very complex parts. In order to give people what they want faster, we should determine exactly what parts of this design document people are most interested in, so that those can be developed first.
Please list the aspects of this design that you need the most, using something like this:
The specific features that I need are:
* item1
Keep them as basic as possible, and give the bare minimum. If the wikidot dev team add your bare minimum request, they can always come back and improve that feature when time permits.
Comments: 14
page revision: 0, last edited: 11 Nov 2009 12:44
The specific features that I need first are:
And highly preferred (I have a workaround using tabview and multiple NewPage modules for now):
(only one tag from the combo box options can be used at a time)
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
To make things simple for users, it seems like the back-end sure can get complex.
I understand this involves a New-Page module, a _template, and the resulting pages in a specified category. But from the existing documentation, I can't figure out how to build it.
Here's where I've muddled along so far — feel free to get in there and tinker.
In my form, I'll start with these fields
In my template, I'd like to lay out the material kinda like this:
summary: %%form{Summary}%%
%%form{FullText}%%
—[%%form{Email}%% %%form{Name}%%]
If the user leaves name/email or the image fields blank, I'd like to default somehow to %%author%% and the first image loaded to the target page. That's the second challenge. My first is to figure out how to get the basics up and running.
Once I've understood the basics, I'd be happy to help with drafting or editing documentation about this feature.
The idea was to keep things as generalised as possible:
From what you've written in this thread (above and below) this seems to be your order of preference?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
I think that's what I'm getting at. But I'm not quite sure until I have more hands-on experience with it. I'll take a look at the examples you pointed to. Thanks.
I've tested forms pretty thoroughly, with the hope that I can get to my holy grail: a form that takes what users give it, but reverts to a semi-sophisticated default when they don't. I've mapped it all out, with examples, and I'm just not there yet — the green cells are successes, the red ones are obstacles.
I'm open to suggestion for how to work with the existing compile sequence. But if there's no way to get there, I'd surely appreciate a way to make form data more useful.
There are a number of instances where fields need to be validated to be of a certain type and not contain illegal characters or html code. For example here are some fields that may be useful:
An Innovator at heart.
That can all be done using formatting, so it would be just that feature that you wanted?
See the MailForm module or NewPage module documentation for more info, as those modules allow you to customise the format of text that is entered.
The example used for an email address (which doesn't allow for gmail's + modifier, I might add)
I haven't read much of this, but I think it explains how to work out what you need to type to get the formatting that you want: Pattern Syntax Description
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
So far, I can only figure out how to recall form-generated data as a single block (in %%content{1}). My first request is to distinguish between each field, as suggested in the (proposed?) documentation — %%field{1}%%, %%field{2}%% — or better, %%MyFirstLabel%%, %%MySecondLabel%%.
Once I've got that figured out, then I can move on to wiki-enabled data, image uploads, conditional data, and data validation — in about that order.
I updated my post above… but here it is again:
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
The specific features that I need are:
This is my priority… just one type (input text) that works
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
Normal text or wiki-syntax-enabled ?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
My priority:
Edit
1. ListPage functionality - A MUST have
2. The 'tag' field type
3. The 'parent' field type
I'll be testing the existing functionality soon and will post back in another sub-thread.
Forms have come a long way recently. Thanks for all the hard work. I'm eager to use these, and I think they'll support Wikidot's goal to simplify the user experience for non-wiki-experts.
Steven has actively taken on a challenge that I share — how to turn form data into functioning wiki-pages. We can view form data through ListPages, but there's no simple way to achieve a standalone, formatted page via a data form.
In the rapidly-evolving data forms documentation, there's this note:
Steven's method works around that obstacle, by calling individual pages with a ListPages module. I'm tempted to follow his lead, except that this method clearly presents new challenges if the user expects the typical wiki experience, shifting easily between editing and viewing.
Does the dev team see full data form functionality through _templates as a high priority, and is there a sense of when you might get there? Thanks.
Support for Data Forms and other variables (inside template/page/list modules) is covered by Standard Template Properties it's in ours nearest plans, can't say right now when exactly.
Bartłomiej Bąkowski @ Wikidot Inc.
';.;' TeRq (Write PM)