[pmwiki-users] NEW RECIPE: EditMore...

[Mike Shanley]

Ben Wilson wrote:
> Why does it *have* to put the categories in a DIV? 
You are right about this: It doesn't have to put them /anywhere/, but it 
does have to put them /somewhere/. The reason is that when the next 
person comes around to edit, all of those categories have got to get 
back into that little input box... and OUT of the pagetext. Thus, there 
needs to be some special marker to indicate the start and end of this list.

It's for this reason that I now make the input box dump it into a (:tags 
[[!what]],[[!ev]],[[!er]]:) directive with Markup that transforms it on 
viewing. Right now, it just hides them in a %comment%, because I do 
understand your logic about keeping scripts well defined.

I considered just dumping them, like you say. I tried it for the exact 
reasons you describe. But it makes a nasty problem with recollection, 
basically because it interferes with collecting from the page text. The 
problems that 1) collecting 'loose' tags to put into the box and 2) 
dumping the box at the bottom of the page, created a situation where 
either: a) my script would fail to do it's job properly in too many 
situations, or b) the user would be driven mad by constraints or 
reappearing [[!cats]] they thought they had deleted. My above markup 
solution solved half of it, but it left collecting categories from the 
page an exercise in stupidity...

My end result leaves two things wanting: the user friendly MyCat => 
[[!MyCat]]
And a variable for what the Markup does with the categories list.

As a result of your message, I realized that by the lack of the former 
user friendliness, which I had honestly just forgotten to implement, it 
allows people to use the box for other secrets... Tags needn't be 
categories. You can fill it with pagelist fmts, notes, \\ for line 
breaks, and a simple %whatever% at the start makes it visible again, 
thereby creating, effectively, a separate, page-specific footer... 
useful for development notes, for instance

If I enabled the conversion, I would have to disable anything but it... 
although perhaps an extra textarea would better suit all of the 
possibilities I just listed... :-p

I want you to know that I do understand your reasoning, but it still 
stands that it would only take moments on my part (or, in truth, anyone 
around here using the script as it stands), to allow the Markup 
described to do basically whatever they wanted. But on the other hand, 
I'm fine to leave it as it is.

> I avoided saying "user!" Oops, I just did.
>   
But do you mean subscriber base as in, for the sake of PmWiki, or for 
the sake of individual scripts? Personally speaking, and this argument 
is probably what bogs so many other open source projects down, it would 
seem to me that larger scripts with easier customization would be better 
for the PmWiki subscriber base... I think this is the goal of the poorly 
used CMS and Blog Package pages, right? Offer people big chunks with 
everything they need...

The problem is that you're still telling people: Install a dozen or so 
scripts, and THEN you'll have what you want. For PHPeople, that's fine, 
but for them, is it even that desirable? It seems like there are better 
ways to keep PmWiki light, but easy for newcomers. For instance, many 
people's scripts will not load when they aren't needed... but MORE 
often, users (or the subscriber base) are required to create if 
statements in their config file--I acknowledge, more efficient, but less 
pleasant. With EditMore, any one of the optional inputs not-wanted by 
the user will not load... Thus, someone who only wants a title input 
will save themselves 3/4ths of my script, so I'm only wasting webspace.

I say this because this is the logic I have in mind when I say, "why not 
make a div?" Though at the same time, I'm well aware that they very 
logic I'm employing is futile because for anyone who wants a recipe to 
being with, you have to be the type who would prefer smaller, piecemeal 
scripts.

Oh geeze... Conversations about a script that are longer than the script 
itself... ;)

-Mike