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?
John Davidson
On 10/21/07, John Davidson <[EMAIL PROTECTED]> wrote:
>
> I will move the link to Wiki Admin over to the left column and will
> also put a button in the same column for those that have
> HasManageNamespacePermission as well as a link to the TopicLocks page.
>
>
>
-------------------------------------------------------------------------
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
