I haven't thought this through in any great length, but it would make sense
to me (at the moment) for TopicName being responsible for deciding what's a
valid name and what isn't and then have each store responsible for actually
encoding/decoding the name in the appropriate store. Not sure how well this
fits in the current workflow and with me about to go on holiday, I don't
have the inclination to look right now ;o) just throwing in my two cents :o)
Derek
On 10/11/07, Nathan Jones <[EMAIL PROTECTED]> wrote:
>
> Hi guys, I wanted to talk about TopicNames again. Mainly this is me
> talking out what I've found and seeing if anyone has any thoughts
> about it.
>
> So, when we last chatted, I think that Craig thought that most
> anything should be valid as a Topic Name, and I tend to agree. This
> means that we would have to work around different aspects of the
> application to ensure that the rules of each particular piece of the
> application/engine that needs to deal with the Topic name would do so
> properly.
>
> I was looking to add to our fw site...[1] and ran into the situation
> where different parts of our app need to protect itself from funny
> characters in different ways. A couple so far: FileSystemStore can't
> handle characters from Path.GetInvalidChars(), the LinkMaker can't
> handle URL "control" characters, The SqlStore probably needs help with
> handling "'". The formatter (argh!) has its own rules of what is a
> topic and that's got nothing to do with anything anyone else says
> about it. The PathInfo mechanism of determining the namespace and
> topic just flat out doesn't work with (certain) URLEncoded characters
> in the Name of the html file... It goes on....
>
> Originally, I mentioned basically making TopicName only accept the LCD
> of all these restrictions, (which is still probably the easiest route
> to take,) but this is overly restrictive in my mind, and doesn't take
> into account the restrictions of whatever someone adds next (A new
> Store, for example) Not to mention, that this would mean that I
> couldn't add my feature[1] and that would displease me.
>
> So, where I am is this.... Each of the various pieces of the app
> (LinkMaker, PathInfo parser, FileSystemStore, Formatter, etc.) has
> rules about what to do to encode/decode and/or recognize the TopicName
> to make it safe for that piece and to reconstruct it to pass on to
> different pieces of the app.
>
> One way is to make each piece responsible for that work, but a) it
> seems easy to miss some existing code that needs to apply this work,
> but doesn't and b) it would spread something logically the same around
> to different parts of the app. The plus side to this, is that there is
> nothing to invent. "Just" find all the places that need to handle
> funky topic names and code around that.
>
> Another way is to try and smoosh this functionality into TopicName
> itself... I don't have any concrete ideas, but I'm thinking something
> like a ctor on TopicName that takes an ITopicNameFormatter in where
> ITopicNameFormatter has a Format and Unformat method on it. Maybe
> override ToString() to accept this guy instead or in addition. I don't
> know of a standard .net construct that would do something similar, but
> if there is we could use that instead of inventing a new class.
>
> I guess that I'll leave it at that... I'll continue tinkering around
> with things, but I would appreciate comments, ideas or experiences on
> this.
>
> thanks, nathan.
>
> [1] I want to create a "bookmarks" page based on the logged in users
> name and then have the topics on this page linked in via some wikitalk
> in the RightHandBorder. Logged in user names for us are DOMAIN\user.
> The backslash in a topic name currently blows chunks in different
> parts of the system. So I started making the FileSystemStore handle,
> then saw that the links couldn't take it either, but for different
> reasons....
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
