[pmwiki-users] Input recipe

[Joachim Durchholz]

Bronwyn Boltwood wrote:

> Alright, I give up!  I don't know what most of the answers should be 
> -- I've never built a working HTML form in my life, let alone the 
> script to process the results.  The most I ever needed to do was make
>  a mockup that looked pretty!
> 
> But then, if you're trying to make custom forms available to the
> great unwashed, then this is exactly the kind of problem they're
> going to have.
> 
> I wonder why HTML forms are so hard?

Because they need to translate between two worlds: HTML and scripting. 
For display, you need visual information; for scripting, you need to 
specify how user actions are to be translated into something that a 
script can understand.
HTML chose to submit name=value pairs to the script, which is a 
reasonable thing to do. However, this means:

For text input controls (single-line, multi-line, password-style), HTML 
needs to specify a control name. The value for the name=value pair is of 
course taken from the control's textual contents (after the user has 
edited it).

For choice controls (radio buttons, checkboxes, selection menus), we 
again need to specify a name, but a value, too; those controls that are 
checked send the name with their value, those that aren't don't send 
anything. I.e. if you have a radiobutton group like this:
   Displayed as  Name        Value
   (o) Radio 1   radiogroup    1
   (*) Radio 2   radiogroup    2
   (o) Radio 3   radiogroup    3
then the script will get radiogroup=2.

There are several additional things that can be set up:
* Every HTML control can be "disabled" - i.e. it will display, but it 
won't react to user input, and it will not send a name=value pair to the 
script.
* Every textual HTML control can be "read-only" - i.e. it will accept 
only user input that doesn't change the contents (moving the cursor is 
OK, copying from the text is OK too, but typing text is not OK).
* Multiline text fields have not only a width but a height, too. One 
could specify the size of such a field via something like
   +------------+
   |            |
   |            |
   +------------+
which would give a two-line field, but it would be *very* awkward both 
for PmWiki to recognise and for the wikipage editor to set up.
* Selection menus can allow single or multiple selection. Yet another 
option.


I think setting up editfields and such using "intuitive syntax" is a 
good idea, and maybe it should be done... but it doesn't scale to the 
full set of HTML functionality, so we'd have to do it as with tables: 
intuitive syntax for the standard case, and full syntax for those who 
need all those options.

To set up an intuitive syntax, we'll have to solve one outstanding 
problem: how do we attach a control name to, say, a text control?
Assuming a 10-column text field is written as
   [__________]
how should the markup look like for adding the control name? It could be 
something like
   [__________]"name"
i.e. the name follows immediately without an intervening blank - I don't 
particularly like that proposal, it's just the first thing that came up 
in my mind (I'm currently programming the regexp rulesets for the 
(:input...:) syntax, so I'm mentally tied up the wrong way to come up 
with anything useful for alternate syntaxes right now).

Regards,
Jo