Well, I wrote all that code (factoring out the built-in topics into its own provider was a huge improvement on the old way of doing it, with special cases everywhere), so you can blame me if it's weird or busted. :)
So this is sort of a tough problem. BuiltinTopicProvider doesn't really have anywhere to persist this sort of thing. Really, it's meant to provide a read-only version of topics. Un/LockTopic are write operations. I guess the smart thing to do is to emulate what happens with WriteTopic: when someone wants to lock (e.g.) the default version of HomePage, write through the default contents to the Next provider and then Lock that. That would mean that calling Lock on a built-in topic would "materialize" it in the underlying store, which I think is reasonable. Unlock should never be called on a built-in revision (since locking would materialize a revision), so I think we could safely implement Unlock on a built-in revision by just no-oping. Obviously, for materialized revisions, both Lock and Unlock would just pass through. Make any sense? > I have made the changes as described and will start writing unit tests > before checking in again, but have found a bug that I am unsure of the > best way to sort it out. In the BuiltinTopicsProvider I check to see if > the TopicIsReadOnly. If it is a true builtin, ie. no HomePage.wiki file > exists in the FileSystemStore for the Namespace, then I return false > as it is not possible to mark the builtin as readonly (at this time). > However, the ContentProviderChain passes through the > BuiltinTopicProvider, before checking the FileSystemStore and as the > Unqualified topic name for HomePage is found in the > BuiltinTopicProvider it always returns false instead of getting the > real value. The file is being locked when requested, but there will > never be a way to unlock it except by changing the property on the > server itself. Needless to say, this is not a desirable outcome. > > The 2 possible options, that I see, are: > > [1]: change the evaluation order of the ContentProviderChain (I have > not investigated how to do this, or even if it is possible); or > [2]: implement a readonly lock in BuiltinTopicProvider. > > Can I get some input, please? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
