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

[Joachim Durchholz]

Patrick R. Michaud wrote:

> On Sun, Sep 04, 2005 at 11:55:41PM +0200, Joachim Durchholz wrote:
> 
>>Here are the potential problems that I see for upgrading. I may have 
>>overlooked some capabilities of the core (:input:) markup - blame the 
>>incomplete docs for that.
>>* The core (:input:) markup doesn't give warnings on misconfiguration 
>>(well, that's not strictly necessary, but it would be nice to be told 
>>the reason if a control doesn't display)
> 
> (:input:) is considered a highly advanced markup; Like advanced tables,
> I didn't want to spend a lot of code and effort trying to detect
> and report every misconfiguration.

As I said - not strictly necessary.

Though I don't think that the advancedness of some markup should play a 
role in the decision whether to emit error messages. Actually I think 
it's the more complicated markups with many potential error causes where 
error messages help more.

I am aware that none of the PmWiki markups emit syntax errors, and it 
would be a change in character, so I admit it's not something that 
should be added at the drop of a hat.

Adding the error messages in my recipe was also a kind of test, so see 
how it works out. I found it quite useful - when I was using the 
(:input...:) markup, I was making all kinds of silly mistakes, and the 
error messages helped me pinpoint the option that was misspelled.
Of course, YMMV.

>>* The core (:input:) markup doesn't allow me to specify an encoding. I 
>>need multipart/form-data, the core markup doesn't specify anything so it 
>>will stick with the standard application/x-www-form-urlencoded (which 
>>has trouble with umlauts IIRC).
> 
> This can be easily added.
 >
 >>* The core (:input:) markup doesn't do readonly or disabled controls.
 >>One of the recipes I'm currently working on needs both, so the need
 >>isn't immediate but pressing enough.
 >
 > Easily added.
 >
 >>* I can't specify different text input width and text display width
 >>for one-line input controls.
 >
 > Again, this can be added without too much trouble.

Please do.
I'd add it myself in config.php if I knew how. (Seems like it's 
possible, but I didn't understand all the details of the tables and 
didn't want to experiment.)

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

>>* The core (:input:) markup doesn't allow submitting to an arbitrary 
>>script, it can only submit to PmWiki actions. 
> 
> No, one can do (:input form action='some_other_script':).

OK - I found out about that a few minutes after posting.

>>Finally, let me add that I have some personal feelings about that. I've 
>>spent some weeks (and lots of exchanges on this mailing list) writing 
>>and optimising the Input recipe. I can understand if Pm decides for a 
>>different design, but
>>
>>* having my work "conflicted out" of PmWiki by having its markup 
>>namespace occupied by core PmWiki elements,
>>* getting no ahead warnings, just surprise error messages when I upgrade 
>>(I shudder at the possibility that I had upgraded - and hence broken - 
>>one of the wikis in productive use...)
> 
> Sorry, but I don't think it's entirely fair to claim you were blindsided
> by this.  As early as June 22 I indicated an intent to use "(:input ...:)"
> in the core:
> 
>     Hmm, I was thinking of using "(:input ... :)" as a possible markup 
>     for the edit form.  Should we see at all about merging these ideas 
>     together, or should they remain strictly separate?
>         http://www.pmichaud.com/pipermail/pmwiki-users/2005-June/014317.html
> 
> On June 23:
>     I've gone ahead and thrown together a sample recipe for this at
>     http://www.pmwiki.org/wiki/Cookbook/Forms.  It's *very*
>     preliminary and needs a lot of work, but it gives an idea 
>     of the direction in which I think forms handling (at least
>     for PmWiki internals) will go.
>         http://www.pmichaud.com/pipermail/pmwiki-users/2005-June/014340.html
> 
> June 24: 
>     While the forms markup is likely to make it into the distribution,
>     I don't know if background data threading needs to go in the distribution.
>         http://www.pmichaud.com/pipermail/pmwiki-users/2005-June/014363.html

Sorry, none except the first message even mention syntax, and the first 
one doesn't make it clear it's a determined decision.

> What's more, the (:input:) markup went into PmWiki core as of 2.0.beta44
> (July 10), so it's not like I left this intention unrealized for a long
> period of time.  

Sure - I didn't upgrade for a while. Some of the intermediate releases 
had problems, and I was somewhat busy with other things, so I decided to 
wait until the 2.0 release.

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

> And I had assumed based on some other messages that you were designing
> the Input recipe to maintain compatibility with the Forms recipe that
> would be going in the core.

No, I didn't even look at it.
Actually I see no way to make it "compatible" - the recipe and the forms 
core have about 90% of overlap in their semantics, but 0% of sharable 
code. There's simply no way to make it compatible - at best, it can be 
made orthogonal (but see below).

>>* getting a core solution that doesn't do everything that Input does, so 
>>doesn't leave me with a clear crossgrade path
>>* finally, leaves several things to be desired in various more technical 
>>areas, such as error reporting, providing reasonable default values for 
>>attributes that HTML Simply Didn't Get Right, 
> 
> I think this is simply a difference in philosophy about what the
> core implementation of forms handling should do.  In keeping with
> PmWikiPhilosophy #3, I'm aiming for a very lightweight core 
> implementation that could be extended by others.

As long as it can be extended, it's OK by me.

The problem is that the extension facilities are there (I could see that 
from the sources), but undocumented.

> At any rate, I totally understand your frustration at having spent
> a lot of time on the Input recipe and have it not work after 2.0.beta44.
> My apologies for that, I really thought you were following along more
> closely and had it taken care of.

The only way to make it interoperate with the current core is to use a 
different syntax. Something like (:input2...:) or whatever, so make it 
orthogonal to what the core does.

However, I don't think that it makes much sense to duplicate core 
facilities in the recipe. It would be better to change the recipe to sit 
on top of the core and extend it with the functionality that I need.

>>2) I'm not interested in maintaining duplicate work that's already 
>>PmWiki core functionality. Is there a path to integrate the missing 
>>features of Input into the core?
> 
> 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.

 > and reporting into the core unless there's a huge demand for it.

As I said, error reporting is a minor issue. I think PmWiki should 
output a *lot* more error messages, particularly if the markup is 
complicated.

A good indicator of a missing error message is if a problem is 
frequently asked on this mailing list :-)

But that's really an entirely different topic.

 > My intent
> for (:input:) is that it's there for admins who want a quick way to
> embed forms in wiki pages, and that it assumes the admin understands
> at least a little bit about form markup.

That's OK with me. Input did just that. The philosophical differences 
are just these:
* Error reporting (discussed above).
* A more powerful HTML generation engine for the next few things
* In some cases, different names on the PmWiki side than on HTML
* Default values for some parameters that don't have defaults on the
   HTML side
* Some parameter munging (only one parameter)

None of the differences are heading too far away from PmWiki. I know the 
renaming and munging stuff didn't appeal to you, but it's really not a 
"direction" thing IMO.

 > Anything more than that I think ought to be a recipe.

Regards,
Jo