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 _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
