Discussion of the advantages and disadvantages of introducing a dynamic language like WikiTalk to FlexWiki

I got to see this in action a couple of days ago. It is very powerful and exciting. But it will be possible to allow this BehaviorExpressionLanguage to exist in individual pages of the wiki. So normal users might very well be exposed to it, even though we don't expect them to write it. On the other hand, we're already doing some complex things with the @@blah()@@ behaviors and that hasn't been a major problem. -- TommyWilliams

I think putting code for navigation in the wiki doc or doing panels, buttons and stuff like this has one main disadvantage: it would break the seperation between content and behaviour. so far all the behaviours create some content that could be formatted very easy in a pdf or doc or whatever. if complex behaviours would add behaviours like searching, buttons, navigation panels, etc. they would require a very tight coupeling to the formatters and the clients for putting out some javascript or whatever. I also think that it would make one WikiPage look much more frightening for beginners. -- BenediktEckhard

Like TommyWilliams, I had a chance to see this in action the other day. After the demo Tommy asked DavidOrnstein if he had ever thought about making certain properties invisible to editors in Edit mode, by default. He reasoned, rhetorically I think, that advanced properties and behaviors might be confusing to some users. I agree. So here's a scenario: you drop into edit mode and the only WikiText you see is simple text. In the WikiPane on right, under Formatting Tips is a button entitled, DisplayAdvancedWikiText or something of the sort. You click it and things like {TopicIndexBehavior} and Version: appear in the edit pane. It's that simple. Going one step further, I think that all .wiki topics need a page behind. Currently, we have .wiki and .awiki ('a' for archive) files in the WikiBase. I propose that there be a third .*wiki file called .pwiki ('p' for properties). Each .pwiki file could contain information that might otherwise appear in the .wiki file but which does not necessarily have to. Example properties include keywords, owner, summary, parent, relative, previous, next, datecreated, datemodified, and whatever else you can imagine. -- KorbyParnell

I just read through the various pages regarding WikiTalk. Its a quite intriguing concept. Assuming that casual users had a way to benefit without directly enountering its complexities, it is easy to see that more and more wiki functionality could be implemented and exposed this way, progressively layering on and extending a very simple core engine. That said, assuming I'm interpreting things correctly based on what I've read, something about the way WikiTalk appears to have been implemented is rubbing me the wrong way - as a little language with its own types, where those types resemble .NET types but may not be the actual types (inferred from reports of bugs that don't exist in the native types). Again, assuming I'm reading things right, I have to wonder why a little language is being built and why basic types are being re-implemented when instead an object model for the various wiki constructs could be built and then exposed for scripting via any .NET language. No new little language to learn, full reuse of framework types, performance of compiled code, etc. I can think of one reason for the current design, that being to try to create a standard that can extend past FlexWiki and .NET, but can someone shed more light on the reasoning behind the WikiTalk design? -- JeremyGray

I agree with CraigAndera. The Idea with the Code behind isnt that good. Basicly its not a bad idea, but it isnt very helpful. Korby is talking about Example properties: keywords, ... but it is very important that normal users can easily set those properties itself. Currently it is solved with the WikiPageProperties, and thats ok and simple. But the potentialities of WikiTalk in "Special use pages" is very remarkable. I have programmed my own Boarders (see _NormalBordersRightOnly). I am not familiar with C - Like programming Languages, but I could make my own Borders. Otherwise, no normal User is making IndexPages. May it will also be useful with Templates (if they will be implemented sometime) -- SimonSchmid