
![]() |
Show Changes |
![]() |
|
![]() |
Recent Changes |
![]() |
Subscriptions |
![]() |
Lost and Found |
![]() |
Find References |
![]() |
Rename |
![]() |
Administration Page |
| Search |
History
| 1/24/2008 8:46:05 AM |
| FLWCOM-jwdavidson |
| 10/5/2007 12:14:14 AM |
| -61.153.43.246 |
| 3/28/2006 9:21:25 AM |
| -38.116.3.15 |
| 3/27/2006 5:39:36 AM |
| -68.209.248.222 |
| 3/27/2006 5:39:08 AM |
| -68.209.248.222 |
![]() |
List all versions |
In progress.... Saving because I keep losing my work! I had a nice breakdown of before and after. Should I get done pouting, I'll redo it....
(I had step-by-step of old here...)
Basically, the old stuff broke up a line too much and processed each piece of a line separate from the whole line. It did this in an effort to preserve escaped text, but it ended up not being able to handle FormattingRules that enclosed the text. Additionally, FormattingRules were applied in inappropriate places such as URLs, (which basically need to be implicitly escaped because of what they are.) Another place that the formatting kind of punted was when a link was shown with the "Pretty Link Name":http://ugly/url/or/topic formatting. As soon as it saw this type of link, it stopped processing the line.
Example:
This line would be expected to result in the whole line in italics and the text "WikiTopic" not a hyperlink
_Here is an escaped ""WikiTopic""_
However, the old Formatter would process the line thusly:
_Here is an escaped ""WikiTopic"" _
So the output was this:
_Here is an escaped WikiTopic_
Another:
http://localhost/my_files/file_name.html
Would get Textile formatting applied to it because URLs were not always treated special.
(I had more examples....)
The new stuff starts taking stuff out of the line, (be it escaped text, behavior result, or URL, etc.) and pushing it on a stack, replacing the original text with a marker (that has no other processing information.) Once the entire line has been processed, the stack is popped and the markers are replaced with the original text.
(I had step-by-step of new here)
I'm not done. I got to a point where I wanted to get it looked at by someone else and checked in. There are several more bugs that fit in this general area that I'd like to see addressed. I'll be working on those shortly...
Also, the code that did all this formatting was kind of spread out and disjoint. (In one case the same logic of looking for behaviors was done twice, once in a method and then again in the method the first one called.) I've tried to address this and make it a little easier to follow and possibly even more performant. I plan on refactoring this even more and pulling some of this code out into a separate class.
One thing in particular that I did was for the emoticons. It used to do something like 30-40 calls to LinkFormatter.ImageLink, (building up a link to the smiley image,) even if there was no emoticon in that line. I added some shortcutting so that it only calls into this method when it has a hit. (Hits will take a smidge longer because it has to find the hit, and then go get it, but I figure that emoticon hits are a helluva lot less likely than likely.)
Finally, I realize that this stuff is mostly throw away since 2.0 is going to do away with this class and logic. Still, the bugs that I've addressed and plan on addressing make it worth it to me as a user, and if nothing else, it provides some test case logic that the 2.0 stuff will need to be able to handle ![]()
Comments welcome...
-nathan
27-Mar-06
The last bug, 1456956, was introduced by this change. The new logic uses Regex classes to handle the various delimiters (such @@ @@ and escaped text delimeters.) I was being overly ambitious on the re-use of the Regex Matches. I think that I can actually go back and make it more streamlined, but I wanted to get a quick patch in to fix the broken situation first.