> I think the correct behavior should be that when the WikiTalk finds it > is not able to read a Topic it should ignore that particular Topic, > rather than return an error that stops the process.
So, thinking about it a little more, I'm not sure whether this will work or not. Hopefully so, but let me "talk" through it a bit. The logical model that the engine provides is that if you're denied read to a particular topic, you're allowed to know of its existence, but not to find out anything else about it: contents, last modification date, author, etc. That means that if you have WikiTalk that does a double loop over all topics and then emits all the modification dates of that topic, you could get into a situation where the first loop returns a all the topics - even the ones you can't read - but the second loop chokes trying to figure out the modification date of one or more of them. Complicating matters further is the fact that a change of permission while iterating might mean that you're able to see some properties but not others. What this means to me is that it's not clear whether it makes any sense to talk about "pretending it doesn't exist". If you've already written the beginning of a row in a table that you're emitting via WikiTalk, what do you do if you can't read the property that corresponds to the third column? There are a few possibilities that I can think of: 1) Be sure to return default values for any query that results in an AuthorizationException. For instance, Modified might come back DateTime.MinValue. 2) Filter every list of topics by calling HasPermission on the whole list, removing any topic that doesn't allow Read. Note that this is still susceptible to the race condition mentioned above. Maybe that's okay. Of course, what would be really great [1] would be providing an IQueryable<> implementation over the topic store... :) [1] Totally kidding. One rewrite of the entire engine is enough for me this decade, thank you. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
