Feature Proposal: Group names should be language independent

Remove English dependency from group naming.

Motivation

Group names must end in Group. That is weird, geeky and actually quite unusable in non English languages. Like: "Die ProjektGroup" (Die Projektgruppe), De VeranderGroup (de Verandergroep), "le GroupeDeProjetGroup" (le groupe de projet).

Description and Documentation

To sort out.

Impact

To sort out.

Implementation

-- Contributors: ArthurClemens - 22 Mar 2012

Discussion

Yes! This had long been a common issue for new foswiki users. Create a group not ending in group and become locked out. The error checks now prevent that mode of failure, but really we should not be dependent on topic naming at all. Groups, like users, should be identified by an attached form.

Really it should apply to all topic names. We claim to allow mapping of key names using LocalSite preferences {SandboxWebName}, [UsersWebName} etc. These need to be fully tested and formally supported. *Group topics is just one of the challenges, especially if we plan to implement unicode support.

-- GeorgeClark - 22 Mar 2012

Please note that this is pretty much a TopicMapper specific simplification.

it is similar to the naming mess we have wrt *Template topics (er except there its worse, as View/edit templates also end in template, and thus mess up the create topic template dropdown

and the WEBFORMs setting mess.

I wonder if we should just admit that using topic names for classification is unsustainble, and use either a dataform (slow at medium scale) or subwebs (really fast everywhere)

mmmm, did I just propose

System/Users
System/Groups
System/View
System/Edit
System/Topic

Main/Users
Main/Groups
Main/View
Main/Edit
Main/Topic

aliased to whatever the admin sets in configure (rather than renaming the on disk dir/topic names) store2 has the ability to map these names in the store (so the core never sees the on disk form)

-- SvenDowideit - 23 Mar 2012

I've been pondering this sort of thing as well.

Not only VDBI but also ...

I've a work management application which consists of many Forms (many common fields). They are all ActivityForms one way or another. To help control the application each of the DataForm definitions had a DataForm added. This dataform determines such things as which activities can be added beneath other types of activity and the order in which to offer the Forms in an option list.

Therefore, although I agree that a DataForm added to various topics to determine if it's an access-group, or view-template, or data-form-definition or whatever, makes perfect sense. In the situation above, it would now mean that I need two DataForms on one topic. Therefore, we really need to sort out multiple DataForms

A further thought is to imagine an AspectForm used to identify the topic type (aka aspect). What if different types of aspect need different fields in the AspectForm? Do we not need to support multiple AspectForms and if so how do you identify all the aspect-forms?

Finally, at the back of my mind while working on VDBI has been an RcsPlus concept. This would build on top of RcsLite (after some performance TLC applied). Basically, you could have a directory created with the name of the DataForm, e.g. TaskActivityForm, RiskActivityForm etc. This directory would then contain symlinks to the actual topic containing the form. It's really just acknowledging that a directory is an index (albeit crude). My thoughts are limited to DataForms only as that's a really common access path, and trying to add too many alternates would just get messy.

This would then suggest an AspectForm directory, which would potentially speed up finding groups, templates etc. Maybe that should be a GroupAspect directory and a ViewTemplateAspect directory etc. Of course, we need a way to identify all of the aspect definitions, without relying on the name ending in Aspect. I think this will need to be an extra piece of META, possibly META:ASPECT{name="Group"} etc. added to some DataForm definitions.

This is similar but different to Sven's subwebs idea (both use directories as a speed-up mechanism).

-- JulianLevens - 23 Mar 2012

Hi Julian,

I've been thinking about multiple dataforms and aspects too. I agree that using dataforms in their current state would cripple those of us that want to apply our own dataforms everywhere we want.

I'd love to see your thoughts here taken into a more specific discussion about re-thinking dataform. Sadly I can only find BrainstormingDataFormDefinitions and DataFormInheritance right now.

So my preference at this time is Sven's Subwebs approach, for this particular problem. This also has the benefit of reducing the number of different types of things all co-existing in the same web (which mightn't be a problem for VDBI, but in MongoDBPlugin we can only have 64 unique indexes set in any given collection).

Speaking of Mongo, you mentioned directory-per-(aspect/dataform) which we also considered for the MongoDBPlugin implementation (collection-per-dataform).

-- PaulHarvey - 28 Mar 2012

Users have got a UserForm.

Groups could have a GroupForm.

-- MichaelDaum - 10 Sep 2015

Commenting is disabled while not logged in