[pmwiki-users] NEW RECIPE: EditMore...
up at upisup.com
Sat Sep 1 10:56:17 CDT 2007
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 =>
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
Oh geeze... Conversations about a script that are longer than the script
More information about the pmwiki-users