[pmwiki-users] Upgrading to 2.0 breaks Input recipe - how to proceed?

Patrick R. Michaud pmichaud at pobox.com
Tue Sep 6 16:01:22 CDT 2005

On Tue, Sep 06, 2005 at 09:28:39PM +0200, Joachim Durchholz wrote:
> >>* The core (:input:) markup doesn't do readonly or disabled controls.

Now added for 2.0.3; one can do "disabled" or "readonly" after the 
value parameter to get the desired result:

    (:input text aname "a value" disabled:)

Or these can be explicitly specified after the control type using 
something like "disabled=disabled":

    (:input text disabled=disabled name=aname value="a value":)

> >>* I can't specify different text input width and text display width
> >>for one-line input controls.

Now added, using the standard maxlength attribute:

    (:input text size=15 maxlength=100:)

> >>* The core (:input:) markup doesn't allow me to specify an encoding. 

Now added, using the "enctype" attribute:

    (:input form action="..." enctype="multipart/form-data":)

A site administrator can make this the default encoding for all
forms with:

    $InputTags['form']['enctype'] = 'multipart/form-data';

I'm open to developing shortcut names somewhere for the different 
encoding types, but 'enctype=' was the easiest to built up-front and
directly matches what an HTML author would expect.

> >>* The core (:input:) markup doesn't do menus. I don't need them right 
> >>now, and may not need them for some time to come, but I *will* need them.
> >
> >I'm still deciding what I want to use for a markup for this.
> What are the options?

I'm still working on it.  One is the (:input menu:) ... (:input menuend:)
that you've developed, but I'd like to explore some alternatives.
Another possibility is something like:

   (:input menu 
       "First item"
       "Second item"
       "Third item" :)

> ...
> >In fact, all of this is exactly what the "beta" label has intended
> >to convey -- that some parts of the core are still under design.
> Um, well, if that were really a justification, nobody should have 
> developed recipes or templates for 2.0beta.

OTOH, the vast majority of recipes (over 90%) that have been developed
for the beta series work directly in 2.0.0.  AFAIK there are only a 
very few that ran into issues in the upgrade.

> >Some easily added features (identified above) can go in, but at the 
> >moment I'm not planning to put form output validation
> Not sure what you mean with that - Input doesn't validate anything.

I meant what you're calling "error handling".  I should've probably
said "markup error handling", I was trying to distinguish it from
"form input validation" which generally means to validate the values 
entered into a form as opposed to the form itself.

> [...] The philosophical differences are just these:
> * Error reporting (discussed above).
> * A more powerful HTML generation engine for the next few things

I'm probably not going this direction anytime soon -- PmWikiPhilosophy #3.

> * In some cases, different names on the PmWiki side than on HTML

Because forms handling is nearly always intimately tied to a CGI
script that will be receiving the form data, and such CGI scripts
document their inputs using HTML markup, I think the PmWiki form
markup should use the same names as HTML markup instead of introducing 
new ones and having admins have to figure out the mappings.

> * Default values for some parameters that don't have defaults on the
>  HTML side

The core forms.php allows defaulting of values.  (Or are you
indicating that it shouldn't?)

>* Some parameter munging (only one parameter)

Parameter munging will probably be supported at some point.


More information about the pmwiki-users mailing list