Markdownなどの既存の構文を使用するというSinanのアイデアは優れていますが、この種のアプローチの実行可能性は、状況の詳細によって異なります。あなたは私たちに非常に役立つ回答を得るのに十分なことを言っていません。白紙の状態から始めているのですか、それともスタッフの再トレーニングは言うまでもなく、コストのかかる変換プロセスを必要とする既存のドキュメントの大部分を継承していますか?
後者の場合、短期的な回避策と長期的な戦略の観点から考えて問題に取り組むことが最善の場合があります。短期的な回避策(あなたの質問で提案されたものとまったく同じようなある種の自家製の構文)は醜く、あちこちで面倒を引き起こす可能性がありますが、それは仕事を成し遂げることができます。たとえば、私たちの組織には、最終的にHTMLページのコンテンツを提供するWord文書が大量にあります。これらのWordファイル内で、スタッフはこのようなアプローチを使用してリンクを作成し、解析コードが処理する他のいくつかの宣言を行います。##some_link##
。これが失敗する方法はたくさんありますが、私たちが作成しているコンテンツの種類では、それが発生することはめったにありません。その理由の一部として、コンテンツをより堅牢なシステムに移行するという長期的な戦略に多くの熱意を生み出すことは困難です。##foo##
私の期待は、そのような移行が発生することですが、それは、私たちの厄介なマークアップデバイスの制限ではなく、より大きな考慮事項によって推進されています。
アップデート:
追加のコメントに基づくと、短いIDを使用して、ユーザーがすばやく追加できるようにするリンクのリストがあるようです。したがって、これらのリンクはどこかで定義されます。たとえば、Perlハッシュです。このハッシュを使用して、無効なエントリを防ぐことができます。例えば:
use strict;
use warnings;
my %approved_links = (
so_perl => 'http://stackoverflow.com/questions/tagged/perl',
so_ruby => 'http://stackoverflow.com/questions/tagged/ruby',
);
my $regex = qr/ \[\[ ([^\]]+) \]\] /x;
while (<DATA>){
die "Danger: $_\n" if map {
exists $approved_links{$_} ? () : ($_)
} /$regex/g;
s/$regex/$approved_links{$1}/g; # Not complete, but you get the idea.
print;
}
__DATA__
Some text [not an id] [[so_perl]] more [[so_ruby]] more..
[[so_perl]] blah [[so_ruby]] blah
[[bad id!!]]