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

Joachim Durchholz jo at durchholz.org
Sun Sep 4 16:55:41 CDT 2005


Hi all,

I'm having serious trouble upgrading PmWiki sites that use the Input recipe.

After some analysis, it turned out that the problem is that PmWiki now 
has an (:input...:) markup in the core, and the Input recipe redefines it.

I'm now stuck between a rock and a hard place. If I leave the Input 
recipe enabled, editing doesn't work (the Input recipe doesn't know 
about edit forms, and it's not the right place for doing that anyway). 
If I disable the Input recipe, that will break those sites that use it.

How should I proceed to upgrade those sites that use Input?

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)
* 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).
* 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.
* 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.
* The core (:input:) markup doesn't allow submitting to an arbitrary 
script, it can only submit to PmWiki actions. A workaround would be that 
I define an action that simply calls out to the script that should 
really handle the stuff, but I don't like the overhead (PmWiki is a 
largeish script, and PHP adds its own form processing, too) and the 
error sources (making sure that all the parameters are passed through 
with the correct quoting). I wouldn't want to fork to a script that does 
uploads, for example, both efficiency-wise and bug-wise.
* I can't specify different text input width and text display width for 
one-line input controls.


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...)
* 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, or generating HTML that's 
not a simple 1:1 markup->HTML translation for that extra flexibility 
that keeps the markup short and simple and allows specifying default 
values for textareas - it's galling if you spend a lot of time and care 
to get these things right, just to find that you can scrap all that work 
because it was rendered incompatible...

... um, well, let it suffice to say that I needed several hours to cool 
down and write *this* mail instead of a quite different one.


That said, I'm more interested in hearing about ways forward than in 
apologies. Apologies are nice and all that, and provide warm fuzzy 
feelings, but my clients are interested in results ;-)

More specifically, I'd like to hear about two things:

1) How do I upgrade those wikis?
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?

I'm not in a hurry to upgrade right now, so if the answer to question 
(2) is a Yes, I could infer an entirely satisfactory answer to (1) myself.

Regards,
Jo




More information about the pmwiki-users mailing list