[pmwiki-users] Upgrading to 2.0 breaks Input recipe - how to proceed?
jo at durchholz.org
Sun Sep 4 16:55:41 CDT 2005
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.
More information about the pmwiki-users