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

Patrick R. Michaud pmichaud at pobox.com
Mon Sep 5 16:47:29 CDT 2005


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.

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

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

> * 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':).

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

> 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

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.  

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

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

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.

> 1) How do I upgrade those wikis?

I don't know.  I didn't familiarize myself all that closely with the 
Input recipe because it seemed to be heading a different direction
than where I was intending to go.

> 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 and reporting
into the core unless there's a huge demand for it.  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.  Anything more than that
I think ought to be a recipe.

Pm




More information about the pmwiki-users mailing list