[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.
Pm
More information about the pmwiki-users
mailing list