Loading...
 

TikiContextAwareness_gmuslera

For us we have philosophic questions like where we come from, who and where we are, and thing like that. I think that Tiki components could be improved if they can ask themselves the same questions.

The Tiki object set is pretty flat, almost one-dimensional. We have objects all in the same level, we see almost all the system content in the same level, and the very few exceptions (like wiki page attachments, categories, forums) dont have the help of the environment to show that now we are in a different place (i.e. not in the "root" objects). I have proposed a bit of more deepness in the content arrangement (mostly for the future core, but a lot is applicable to current object tree), be it in how objects are named (like is described in TikiNameSystem, maybe with "/" as separator instead of "." like in my thread about Core that could have nice effects in resulting URLs) or in how are interrelated (like in TikiIntegration2 ), but this things, and actual system, could improve with a bit of context awareness.

The modules are the most obvious targets of this kind of things. Think in the Search module, that will search in the entire system, whitout asking itself where it is. But if you are in a forum maybe the search could be done in the current forum, or if we are in a category (i.e. Documentation) we could want to search in the objects of the current category, or if we are looking at some user page, search in that and other user owned objects. Last-modified modules, and Top-ten modules can also be improved that way. (or have alternative, context-sensing top ten and last modified modules). But the idea is that when I am in some way "inside" a category, the system know where it is and adapts to this situation.

If the object architecture permits more deepness to have a more 2D structure like having wiki pages attached file galleries that have attached image galleries that have attached a blog, well, the context awareness is a must. Components should be very aware of what user they are running as, what object they (or some else) are displaying now and the entire "path" of that object, i.e. with mycategory/mywikipage/myfilegallery/myimagegallery/myblog, the parts that make the page must be aware not only that they are displayiing the blog, but also all the way up.

But there are more advantages and meanings in context awareness. Objects could be also compound objects (i.e. not one as attach of the other, but an (un?)ordered set like a category). View such objects could be made doing a tiki-view_compoud.php that call the view program of each of those components, but, why not do just a "view" (or edit, or list, etc) program, that understand what he should show, and call the appropiate methods for the parameter? a problem for this is that different kind of objects have different namespaces, I can have a wiki pge, a file gallery, a blog, and a forum, with the same name (right now, well, in fact, there are few categories of "named" objects because most of them are in fact named with a number instead of a name, that iis a little more than an attached comment in the practical sense, but maybe could be improved like i described in TikiNames ).

Speaking of that kind of simplifications, if we know who and where we are, maybe security checkings could be simplified also. An i.e. iamenabled() function (maybe with an action parameter) that could do all the checkings for the current object (and all the way up also), the current user, and the action, and use it as a single point of security checkings and simplify the module development, hiding all the object, user class, and system security restrictions from the actual tiki components. It could be even used as a fast way to implement WYSIWYCA, doing the enabled check before even showing a link to the object.


Page last modified on Sunday 21 September 2003 20:54:55 GMT-0000

Upcoming Events

No records to display

Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.