This started thinking in posting something about Core and Users. After all, users look like something that should be in the core, at least to support security. What will be the core users data? I think that nothing more than username and password, but modules and extensions will modify the user database adding fields, or have more tables for additional data (i.e. the avatar, or geographical data, or even site specific data that the administrator wanted to add, that with maybe a form editor extend the user data to be able to hold more site specific info).
But, what about having the user data put along with the content data? and be extended in a similar way? You could have a core "user" class, that have a username and a password attributes, and extension of this class have more data... and my thread of thinking started to follow the problem of relating the additional user data with the "real" user for all the features and extensions. Then I thinked... why not have extensions of the "user" class with names that extend the original class? i.e. to have a content data of the class user.avatar, that is the extension of the user class, where the "basic" data have as key the username and the "user" class, but the avatar info is in another record with key the user name and the "user.avatar" class.
The topic of names and namespaces is something very common in my postings, have something about this in TikiNames_gmuslera, something more in TikiNameSystem, and more in some of my writings, including TikiIntegration2, so the idea of having an hierarchical namespace for class names is an evolution of all of this.
But... how many namespaces? or a single one? or a common way to say that a name belongs to some namespace in particular, or is some kind of object? I think that all of this discussions could give us a way to have an unified way to use names for Tiki objects, in the most broad sense, and most of this discussion not have to be just for core.
There are a lot of ideas that derived from this, some for actual tiki, and some that will require development from core:
- Have a "resolver" of names, something that could be tiki-index.php or what apache redirection points to after a url with some kind of parameters. That should search in the namespaces to see what object fits better. This could be enhanced using more names in the tiki objects (i.e. instead a gallery number, to have a name for them.
- A result of the previous one... why not have wikified names for all objects? Something like a name for URLs, and a description-like name for showing/listing/etc.
- What about having namespaces a la perl? with a character at the start to define what namespace applies there, like $awikipage, @aclass, ½anuser or things like that. I think on in to have different characters for a blog, or an image gallery, etc, but then I realize that there is not enough printable, non-reserved chars for the amount of actual or future kind of objects.
- Another alternative, to have names, like class.wiki or user.gmuslera, or .things like that. The names could be core names or evolved names, like user.avatar.gmuslera or user.gmuslera.avatar, or a more objectoriented-like syntax like user.gmuslera->avatar or alternatives with a URL friendly charset.
In general, I think that having hierarchical namespaces for most things in Tiki is a must. Some names could have context related shortcuts (i.e. when I'm talking about classes something without prefix should be a class name) or prefixes/suffices that discriminate namespaces or kind of objects. And even the namespace could be a common one, and with this in mind, most objects could be stored in the objects database, with a common name that could be key to refer to it and obtain attributes.