| At line 31 changed one line |
| <<dda7d0fa6d68b30c5803e5427987a509>> |
| [{dda7d0fa6d68b30c5803e5427987a509>> |
| At line 35 changed one line |
| <<TableOfContents(3)>> |
| <<TableOfContents(3)}] |
| At line 41 changed one line |
| Since the markup is not transferable between wikis, the exact text that appears between << and >> is totally irrelevant. |
| Since the markup is not transferable between wikis, the exact text that appears between [{ and }] is totally irrelevant. |
| At line 69 added one line |
| I'm more concerned that there is introduced an opportunity for errors and lost data. What should the wiki do when there is an unknown placeholder? What if the placeholder is duplicated? Data loss is possible when the user tries to move text between pages, or even on the same page, but in two edits -- he will cut the text, save to see how it looks, edit again and paste the text in different place. There is also a possibility of accidental modification of the hash during editing, either by the user himself, or by the text editor (line breaking, autoindenting, spellchecking, autocompletion). The main problem is that such a failure is fatal -- once you save, even pasting the text back wont help, because the placeholder is already deleted on the server. Sure, it's a wiki, so you can probably revert to a previous version and then retry all your changes -- but this in truns destroys the user's work. Turning the "hash" into an actual "perfect" representation of the data, just compressed and base64-encoded is one solution. |
| At line 70 changed one line |
| [{ALLOW edit All}] |
| To sum up -- I agree that it can be advantagues to use hashes in cases of elaborate elements -- especially when they can contain whitespace and normal text. But at the same time, this has several drawbacks making the whole editor a **little** less friendly and faultproof -- so it seems that the technique can be avoided when it's not actually necessary: when the text of contained object is actually short and robust (no whitespace or other things that could make it look similar to other page content). |
|
| -- RadomirDopieralski, 2007-02-23 |
|
| I suppose the ideal, would be able to use [[http://en.wikipedia.org/wiki/Code_folding|code folding]] to automatically fold/hide large multi-line [[Placeholder]] sections. Novices can safely ignore, advanced users can unfold the section and edit. But its pretty much impossible for HTML/JS I think. XUL/XAML or some other tech would have to be used. |
|
| -- JaredWilliams, 2007-02-23 |
|
| Code folding, syntax highlighting, automatic indetation, templates and autocompletion are elements commonly used to actually //fix the language// used. See how C++/Java/C# programmers become bound to the IDEs they use -- because the code is only in part written by them -- the machine does most of the work. But if the machine can do that work when the code is written, it can as well do it when the code is parsed -- hence all the "generated" parts of code are really superfluous and serve only presentation -- not meaning. It's better to design the markup right from the start, than to patch it with additional functionalities of the editing program. That's what I believe, at least. |
|
| With code folding there lurks another trap -- it's easy to fall for the "myth of experienced user" and start designing "normal" features and "advanced" ones, that are normally hidden and must be enabled in some secret way -- or even become enabled automatically when the program somehow decides that the user became experienced. But there is no such thing as "general experience" -- the user learns to use particular features of a program. If the features are hidden or simplified, how is the user supposed to become experienced with them? The newbie/expert divide is totally artifical and never works as intended. |
|
| -- RadomirDopieralski, 2007-02-24 |
|
| I would have to disagree to the first paragraph. Syntax highlighting (as I use it) is just a real time form of spell checking, similarly auto completion provides the same function. |
| IDEs generate boiler plate code, so the user still has the ability to modify it. |
| I don't think templates are bad thing either, if someone wanted to generate similar looking wiki pages it seems a sensible thing todo. |
|
| I think we're getting to the point where IDEs are getting more intelligent, and being to provide comprehensive re-factoring tools, for when initial design decisions become suboptimal to ever changing needs. Some wikis have incorporated similar functions, like rename pages (analogous to renaming a method and having method invocations renamed), with then causes links to that page to be renamed also. |
|
| Perhaps I was wrong to introduce the divide, as I would appreciate code folding, and would consider myself advanced. |
|
| -- JaredWilliams, 2007-02-24 |
|
| I don't say that it's the only function of these techniques -- they sure are handy in well designed languages too. The difference is often subtle, but when designing a language one should not rely on external mechanisms like these -- it should be easily usable in a plain text editor. |
|
| As for boiler plate code -- if it goes there always, except for very rare cases, woudn't it be saner to design the language so that you have to specify the code in the rare cases, not the common ones? |
|
| Code folding can also be very handy, not as means of simlifying the code for inexperienced users, but as a general means of reducing the visual noise. It can also be handy as some kind of "table of contents" for a class, for example -- I don't claim that the advanced/inexperienced divide is the only function, I just wanted to point out that it is often used in this way. Personally I avoid it -- I rather keep my code clean and not-noisy. I navigate my code by visually characteristic pieces of it -- code folding makes me lost in it instantly, without any hope of telling how far it is to the function I look for -- two pageups? One pagedown? I guess it's a question of personal preferences and style. |
|
| -- RadomirDopieralski, 2007-02-25 |
|
| ---------------- |
| I wonder if anyone would reject if we change the syntax from two to three angle brackets. Since this markup is created by the wiki-engine rather than the user itself, it would be good to reserve the easier to type markup for elements that humans put in, let's say plugin syntax for example. |
|
| {{{ |
| <<<placeholder>>> -> generated by the wiki engine editor |
| }}} |
|
| Also I think nobody is using it right for the purpose it was designed for. |
|
| -- [[ChristophSauer]], 2007-05-03 |
|
| Probably because few of us must have been totally convinced. But the idea (at least for me) was |
| that since nobody minds about cross-engine compatibility, sites which need this could use |
| a prefix or integer numbers for the placeholder tag which wouldn't conflict with plugins. |
|
| -- [[YvesPiguet]], 2007-May-03 |
|
| This idea with the integer number is good, but its not documented well enough in the spec for the [[Placeholder]], obviously everyone has its own ideas about it. Also it is not documented well enough what should happen if another engine gets code pasted in from another engine that contains a placeholder (reminder to myself). Anyway changing the markup here would make the distiction clear between a {{{<<<Placeholder>>>}}} and a {{{<<Plugin>>}}} like described in the [[GenericExtensionElementProposal]]. |
|
| -- [[ChristophSauer]], 2007-05-05 |
|
| OK, nevermind. Using three angle brackets for plugins fit's nicely into the //block element// notion, so I guess we better leave the placeholder like it is, and use three angle brackets for plugins. I added this to reasoning for placeholders |
|
| -- [[ChristophSauer]], 2007-Jun-01 16:31 (CEST) |
.