Content Access Implementation

See also: DatabaseForPreferences DatabaseForAccessControl DatabaseForMETA ADatabaseCalledTWiki TopicObjectModel ModularizationProject SearchingSectionsOfTheTopics NamedIncludeSections FormattedTWikiFormDataInTopicText ReinventingTWiki AlternatePluginTagHandling

The above links contain all the background that has driven this topic; the contributors to those topics are hereby acknowledged and thanked.

In ContentAccessSyntax we reintroduced the idea of a single consistent syntax for access to topic content. This topic discusses possible implementations of this.

From an implementation perspective this approach has considerable attractions. First, a single regular expression can handle all expansions, allowing us to eliminate many full-text RE applications (a major performance killer). Second, representation of content this way is a natural basis to build other improvements around, such as caches, alternative store implementations, and interwiki communications.

None of the following implementations assumes any change to the existing syntax or functionality, only extensions to it. Over time older syntax can be deprecated, perhaps through incorporating a syntax updater in the TWikiUpgradeStrategy.

Proposal 1 - implement as a plugin

• Re-use DBCacheContrib, which already does 90% of what's required.

This plugin already implements much of what has been discussed and even if the syntax requires tweaking, the cost of change is minor compared to a fresh implementation of almost the same thing. It has the additional advantage that this plugin is a cacheing plugin so it is already accelerated for fast searching.

Proposal 2 - re-use plugin code in core

• DBCacheContrib is an OO implementation and as such is made up of classes that can easily be ported into the core. This would allow us to bring a subset of the functionality (search, array, map) and leave the cache (filetime, archive) behind.
• A subset of the DBCache class (one method) provides all that is needed to create the content hash, though it requires minor tweaks.

Proposal 3 - re-implement afresh

• Implement a new parser in the core that maps the various features of the syntax to the existing code in the core.

Questions to be answered

• An interesting idea proposed by RafaelAlvarez and PeterThoeny is that plugins could register syntax extensions in the form of executable methods. How might this be implemented?

-- CrawfordCurrie - 28 Jul 2004

Something among those lines is implemented in AlternatePluginTagHandling

-- RafaelAlvarez - 28 Jul 2004

Cool, Rafael. Added as an antecedent.

-- CrawfordCurrie - 29 Jul 2004

I have recently installed DBCacheContrib and FormQueryPlugin. After getting over the initial learning curve and implementing a number of fixes (or enhancements, depending how you view it) I found that it was extremely easy to get very complex queries done this way. I am currently building a new plugin based on a rewrite of FormQueryPlugin with the goal that most (or all) queries I can do now with the grep-based %SEARCH% syntax can be done also using that mechanism (I have already implemented multi-web searches, for example, and also made it possible that query results, whether rendered or not, can be subject to calculations using SpreadSheetPlugin ). Of course, this plugin can do much more than what %SEARCH% can do...

I found that highly time-intensive searches over large webs (such as when building an interactive filterable table) are significantly faster than %SEARCH%-based queries.

My suggestion is that at minimum we ship DBCacheContrib with Dakar to make it easier for people to use these features. This will give us some time to experiment further before switching to a different storage model. I would rather come out with Dakar now than waiting for the replacement (and testing) of the storage model...

-- ThomasWeigert - 10 Jun 2005