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

[Joachim Durchholz]

Patrick R. Michaud wrote:

Thanks for the things added :-)

> On Tue, Sep 06, 2005 at 09:28:39PM +0200, Joachim Durchholz wrote:
> 
>>>>* 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';

Excellent!

> 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.

If sticking with HTML attribute names is the design decision for the 
core markup, it should probably remain that way.

The Input recipe did things differently, but it's a decision that can be 
reasonably argued both sides, so I don't object if PmWiki core sticks 
with HTML terminology.

We *could* introduce alternate syntax. However, that opens up redundancy 
issues (what if somebody specifies conflicting options?) and new failure 
modes, so if something goes wrong, the author is left with even more 
things to check. IOW unless there's some error reporting facility, I'd 
recommend against making the syntax redundant.

>>>>* 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" :)

Note that this would, in the long run, require PmWiki to handle nested 
markup. The HTML standard explicitly warns that deeply nested submenus 
are likely to appear in the next version of HTML, so the PmWiki markup 
would have to allow things like

   (:input menu
      "First item"
      ("Submenu"
         "Item 1"
         "Item 2"
         ("Nested submenu"
           "Item A"
           "Item B"
         )
         "Item 3"
      )
      "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.

Exactly my thinking.

The issue is just that the incompatibility was entirely unnecessary. You 
could have used a different keyword. You could have contacted me and we 
could have worked out a solution. Maybe you could have done something 
entirely different. Whatever, it could have been done in a cooperative 
manner.
Simply grabbing the syntactic namespace of an existing recipe simply was 
an uncooperative act, to put it mildly. I assume you didn't do it on 
purpose - I have to, otherwise continued cooperation would be impossible 
for me.

>>>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.

As said in numerous places now, it would have been a simple act to 
disable it.

>>* 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.

An excellent reason.

>>* 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?)

No, providing defaults in cases where HTML doesn't is a good idea in 
general. At least for those cases where defaults are reasonable.

It would be nice if the Forms page documented the defaults. Otherwise, 
admins might be left "figuring out the mappings" (which I agree is a Bad 
Thing).

Jo