On 25 Jul 2005, at 17:16, Rev Simon Rumble wrote:

London has just had someone enter a zillion categories: http://london.openguides.org/index.cgi? id=Garden_Centre_At_Oriental_City%2C_Edgware&version=1

I think we need a way to limit this, otherwise you end up with a zillion stubs floating around.

How about using a wiki to edit a hierarchy of categories, giving them all URIs, and having the openguide wiki have people select a bunch of high-level categories from the hierarchy.

I can see what the editor of that node has tried to do, but there has to be a better way, especially given the semantic nature of openguides.

Daniel

On Mon, Jul 25, 2005 at 05:16:57PM +0100, Rev Simon Rumble wrote:

I think we need a way to limit this, otherwise you end up with a zillion stubs floating around.

I had this happen the other week, but, all in some character set I didn't have fonts for. It would be very very cool if, in just the same way that a category is created the moment it becomes non-empty, it could be deleted the moment it becomes empty.

Would this be hard to do? My guess is no, but, I don't really know. It might make saving nodes slower, since every category they were in before the edit would need to be checked for non-emptiness.

Cheers, James

Rev Simon Rumble wrote:

London has just had someone enter a zillion categories: http://london.openguides.org/index.cgi?id=Garden_Centre_At_Oriental_City%2C_...

I think we need a way to limit this, otherwise you end up with a zillion stubs floating around.

I have a radical proposal. The basis of it is "What good is a default autocreated category or locale with no nodes?".

Since the answer is "not a lot", why don't we just delete them?

This could be run as a cron job, once a night. The SQL shouldn't be that difficult (though the syntax for a left outer join is probably different between each DB variant we support).

We probably need a way of tagging the content to say that this is an autocreated node, untouched by human hands, or we could just check the content.

We probably need to delete from node and from content, as these tables should be kept in sync.

My £0.02 before I go to sleep.

Ivor.

Earle Martin wrote:

On Tue, Jul 26, 2005 at 02:38:19AM +0200, IvorW wrote:

...

I have a radical proposal. The basis of it is "What good is a default autocreated category or locale with no nodes?".

Since the answer is "not a lot", why don't we just delete them?

I actually think we should dump autocreation altogether.

It's frustrating to click on a category title in the categories section only to receive a blank stub.

Not strictly correct. The stub page will contain the line

@INDEX_LINK [[Category Foo]]

which is considerably better than nothing. Empty pages are annoying, but many of our categories and locales are just an INDEX_LINK.

It means the behaviour of a link varies depending on where you click it.

I guess we're not seeing this because the cat & loc pages get autocreated on save (which is a bad thing, I think I agree).

Suppose you have a Category Foo but not Category Bar, and a page that looks like this (underscores denote links):

Something Or Other

Address: 1 Any Street Categories: _Foo_, _Bar_

Something or other is a place with lots of Foo and Bar.

For more Bar, see [Category Bar]_?_.

Now, which link do you think people will click on if they're new to the whole system? I'd bet you it'd be the one at the top. But all they'd get would be a blank page. This is a situation you can easily test out for yourself.

I think if a category doesn't exist, a link to it in the categories display should have the question mark, just like a regular link to it would. Keep it simple.

What you are suggesting makes sense. This would mean reusing the link rendering logic that detects whether a page exists, into the rendering of the metadata fields.

Thoughts please, everyone? This has been nagging at me for a while and I'd like to do something about it.

I've been thinking about a different approach. My alternative is to limit the selections allowed to pre-existing categories and locales. These are presented in a dropdown select list with "Add" and "Remove" buttons. There's no freeform textarea for spammers to type in pseudo categories.

I think that most of the work can be done in template logic. But it will mean passing in lists of all categories and locales to the hash.

My £0.02

Ivor.

On 30/7/2005, "Chris Nicolson" chris@c-nic.org wrote:

The problem I see with this approach is that it would work for a well established guide such as London as the locales are already defined for the guide. In new guides, one of the advantages of using the openguides software (and the whole wiki idea in general) is that the admin of the guide doesn't need to decide what the locales and categories should be - they evolve with the rest of the wiki just like the common layout of information or naming conventions employed by each guide. The authors of the content come to a consensus.

I don't think Ivor was suggesting doing away with the ability to add new categories and locales. More that, instead of a big <textarea> you'd get a list. You could add to the list, but it's going to be a couple of clicks and will only create one category or locale at a time.

So the path of least resistance, for those not in the know, is to choose from the list.

This will also solve the problem of Category_Chinese and Category_Chinese_Food -- because you get a handy lookup of the existing categories rather than having to know the convention that is in use.