Thanks for the input Craig,
What I am seeing is that your HasPermission seems to have implemented things
correctly by forcing a second check
// Otherwise, if it is a built-in topic, does it exist in the
next provider?
if (Next.TopicExists(topic))
{
// If it does, whatever is true here is true there
return Next.HasPermission(topic, permission);
}
which has the effect of determining if it has been materialized. I will add
a similar check and see where that takes me. I was just trying to sort out
the reading of the materialized topic, but as you point out it is necessary
to also materialize the topic when an attempt to lock it is made (even
though it will be materialized and locked as the default content).
Also, I have made progress on creating Unit Tests as promised with a number
for NamespaceManager and FileSystemStore. I was less than successful when I
tried to add some to the TopicCacheProvider. The existing tests there are
not easy to follow and replicate. Could you provide some hints.
John Davidson
On 10/22/07, Craig Andera <[EMAIL PROTECTED]> wrote:
>
> 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?
>
>
>
-------------------------------------------------------------------------
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
