
![]() |
Show Changes |
![]() |
|
![]() |
Recent Changes |
![]() |
Subscriptions |
![]() |
Lost and Found |
![]() |
Find References |
![]() |
Rename |
![]() |
Administration Page |
| Search |
History
| 8/7/2006 2:47:33 PM |
| -65.205.71.101 |
| 2/1/2006 12:07:18 PM |
| -131.107.0.104 |
| 11/12/2005 1:43:01 PM |
| -67.68.50.173 |
| 2/16/2005 11:39:57 AM |
| -12.33.164.10 |
| 2/16/2005 11:36:08 AM |
| -12.33.164.10 |
![]() |
List all versions |
@@InterWiki("Google", "Search Google for FlexWiki", "FlexWiki")@@
@@InterWiki("GoogleGroups", "Search Google Groups for FlexWiki", "FlexWiki")@@
The first two parameters are always required (InterWiki key and link text). The remaining parameters are dependant upon the InterWiki being used.
The available values for the first parameter (InterWiki key) are defined - by default - as properties of a topic called _InterWikis. This can be overriden in the web.config file using a key called InterWikisTopic.
If the topic specified in the InterWikisTopic key of the web.config file does not exist - or the _InterWikis topic does not exist if no override key in the web.config file exists - an error is displayed as follows:
Failed to find InterWikisTopic [name_of_expected_interwikistopic].
If the InterWiki specified in the first parameter is not found, an error is displayed as follows:
Failed to find InterWiki [name_of_interwiki_specified].
Here's what the 2 examples under Usage look like based on _InterWikis at flexwiki.com:
Search Google for FlexWiki Search Google Groups for FlexWikiThis change is not checked-in to the GotDotNet Workspace. I would prefer to email the new file and specify the two-line addition in formatter.cs to another developer who's already setup to check-in/check-out files.
Changed files:
New files:
No new tests were created for this behavior.
What is the relationship between this feature and "external wiki references"? -- see External Wiki References in the FormattingRules. It seems like these two things should be combined somehow. Or maybe external wiki references already do what you want?
As currently implemented, External Wiki References don't achieve the same thing. For example, if you wanted to search for "Tommy Williams" (notice the space) on Google, you could set up an external Wiki reference:
@Google=http://www.google.com/search?q=$$$
But then I can't find any way to convince the External Wiki parser to recognize the space (or embedded quotation marks, if you wanted to do that). External Wiki references expect the part before the @ to be a TopicName. Including %20 for the space, or enclosing in brackets [] or quotation marks doesn't work:
Tommy Williams@Google [Tommy Williams]@Google Tommy%20Williams@Google Tommy+Williams@Google "Tommy Williams"@Google
The only one that works is to form it like a topic name:
TommyWilliams@Google
But that's not what you would want to pass to Google for searching.
There ought to be some way to make these two ideas work together, though.
I agree. I looked at External Wiki References initially to try and simulate the InterWiki functionality. I ran into the same problem as described above with spaces in the search phrase. I figured there was probably a way around that issue, but then I came across another - multiple place-holders/variables in the external url. If the external link were something like "http://www.google.com/search?as_sitesearch=$1&q=$2", I don't see how the External Wiki References could handle it, whereas the InterWikiBehavior handles this just fine.
I agree that there's a limitation to what you can have on the left side of the @ in an external wiki reference. One solution would be to allow something like:
"Tommy Williams"@Google
Another solution that seems reasonable to me would be to support the InterWikiBehavior but to have a formally defined mapping from the simplified external wiki reference syntax to the InterWikiBehavior. In fact, it should be implemented that way: in the formatter, translate @@InterWiki("google", "foo", "foo")@@ to
@@InterWiki("google", "foo", "foo")@@
Yes -- I like this idea of mapping in the formatter. That's a great idea.
RyanLaNeve, will you implement this?
Well...I'd love to, except that I'm horrible at regular expressions! I can only seem to get it to work if the search string (left side of "@") is in quotes. Here's the expression I'm using:
(?<param>".*?")@(?<ident>[^\s]+)
I'm performing a "search and replace" at the top of the "DoBehaviors" method of the Formatter class. I use the regex to find the matches, then replace them with equivalent @@InterWiki(...)@@ strings, which then get replaced in the existing code of the "DoBehaviors" method that follows.
Anyone better than me at regular expressions wanna throw me a bone and give me a pattern that works for the following scenarios?
searchstring@Google
blah blah searchstring@Google blah
"search string"@Google
blah blah "search string"@Google blah
-- RyanLaNeve
Actually, I think the idea is to no expand the syntax supported by the @@InterWiki("site", "topic", "topic")@@ syntax that's currently supported. If you want todo fancier things, you'd need to use the @@InterWiki(...)@@ syntax. So to make it work you could probably just change the code that currently processes parsed external wiki links -- which even already has the regex that parses the two pieces out. It ought to be possible to change that code to do the translation. Assuming that that code gets run before "DoBehaviors"...
If you get stuck, let me know. I'll try to help out (here or via email or IM)
Ok, I'm with you, now. I'd stil like to see the "@@InterWiki("site", "topic", "topic")@@" syntax alow for multiple words as the topic, but one step at a time I guess. It turned out the existing code to process external wiki links occured after the code to process behaviors. Since "processing external wiki links" is actually turning into "replace external wiki links with InterWikiBehavior syntax", I just added a regex replace call to the top of the "DoBehaviors" method, using a slightly tweaked version of the "externalWikiLink" regex pattern (needed to be tweaked so that the left-side wasn't required to be a wiki link). This seemed better than changing the order of processing in "TranslateLineElements" to call "LinkHyperLinks" before "DoBehaviors". Having done that, the use of "externalWikiLink" in the "LinkHyperLinks" method can be removed, as well as the "ExternalWikiLink" method entirely.
-- RyanLaNeve
If there will be changes in this area, one goal should be to make ExternalWiki syntax as fast and efficient as InterWiki sysntax. At the moment, there is an enormous difference...