ASDocで壊れたパスを修正していますか？

Question

この質問は、AS3から文書を作成するためにASDocを使用することに関係しています。私はFlexや何かからコマンドラインを使っているだけではありませんが、すべて正常に動作し、ASDocはエラーを返さないが、結果として得られるドキュメントのいくつかのリンクが壊れている。

特に、ドキュメントの他の部分（同じクラスを含む）のプロパティやメソッドへのリンクがある場所では、リンクはパッケージに対応するフォルダを倍にします。

例えば、myPackage.MyClassを文書化しているとします。 MyClass場合MyPropertyというプロパティがあり、どこか私のドキュメントで私はこのような行が含ま：

@see #MyProperty 

はその後、ドキュメントが正しく解析され、「参照：」リンクが正しく作成されたが、それが指して巻き取りますもちろん、実際のファイルシステムに一つだけmyPackageフォルダがある

.../output_directory/myPackage/myPackage/MyClass.html#MyProperty 

へ。

私のASDocコマンドの関連部分は次のようになります。

asdoc 
-source-path . 
-doc-sources myPackage 
-output D:\dev\repository\docs\myPackage_docs 
-external-library-path "C:\Progra~1\Adobe\flex_sdk_3\frameworks\libs\player\10\playerglobal.swc" 

私はおそらくいくつかのASDocリンクのベースURLを指定することになり、引数、またはそれらの線に沿って何かが足りないのですか？これは普通のバグだったとすれば多くの人には明らかですが、私は問題のためのGoogleの結果を見つけることができませんので、私の実際の仮説は、FlexからASDocを実行している人には起こりません。除外されました。

ありがとうございました！

---

TypeOneErrorの提案では、さまざまな種類の@seeリンクを試しました。私は、これらが正常に動作していることが見つかりました：

• @see some.package
• @see ClassName
• @see ClassName#property

これらは動作しませんが：

• @see #property
• すべてのナビゲーション・リンクが働くもののビット悪いことは何
• @see full.package.ClassName#property

が、ある、同じ倍増パスが自動的に生成されたタイプのリンクで発生します。たとえば、各メソッドのシグネチャが表示されている場合、そのメソッドがドキュメント内にあるクラスを返すと、そのリンクは破損します。

また、HTMLを見て、問題がページのベースURLなどとは見えないことが判明しました。リンクが矛盾しているだけです。したがって、連続した@seeリンクの行では、それらのうちのいくつかはClassName.htmlにリンクし、package/ClassName.htmlへのリンクは上記の規則によってリンクされています。これは、ページがフレームで表示されているかどうかにかかわらず、すべてが真です。

私が何かを考え出すなら、さらに詳しい情報がありますが、回避策のアイディアは大歓迎です。

---

更新：いくつかの詳細は：私はそれは、Flex 3を伴うことを除いて、私の正確なSDKのバージョンのわからないんだけど、私は引数なしのASDocを実行する場合、それは報告しますAdobe ASDoc Version 3.3.0 build 4852を。私はクラスパスディレクトリに配置されたバッチファイルから、Windows XP上でこれをすべて実行しています。

---

部分的な解決策：すべてが、私の問題の一つは、のFlex 4 SDKの4.0.0.7219ベータリリースにアップグレード（およびその中に分散されるASDocを使用）により分離しました。今、私の@seeタグはすべて期待どおりに動作します。残っている唯一の問題は、ドキュメントの一部であるクラスを返すメソッドがあれば、ASDocは単にリンクをマングル化するということです。たとえば、署名がClassA#getB():ClassBのメソッドがある場合、そのドキュメントのどこに表示されるのか、「ClassB」というテキストは「packageName/ClassB.html」ではなく「packageName：ClassB.html」にリンクします。これは簡単なバグであるようです。ブリー。私はこの問題を推測すると思います

Answer 1

ASDocは無駄です。 @seeに完全なパッケージ/クラス名を明示的に追加しようとしましたか？

@see myPackage.myClass#MyProperty 

違いが見られますか？

編集

私はあなたの知見に基づいていくつかのテストを実行し、内部プロパティマーカーは私のために働いています。ページ（なしダブルサブフォルダ）にそのプロパティへの直接

リンク#_dispatcherすなわち

@see。私はコマンドをどのように実行しているのか考え直す必要があるかもしれないと思います。例えば、私のコードベースはthuslyに設定されています

/src 
    /com 
     /bkwld 
      /fetch 

は、私は一般的に「SRC」内のASDocを実行します。

asdoc -source-path . -doc-classes com/bkwld/fetch/Fetch 

私はFetch.asにこれらのすべてを試してみましたが、それらはすべてが期待通りに働いていた：

* @see FetchItem 
* @see com.bkwld.utils.Logger 
* @see #_dispatcher 

まず第二の異なるパッケージにロガーページへ連れて行ってくれた、そして第三取得の保護方法にページをジャンプアップ、FetchItemページに連れて行ってくれました。

ちょうど好奇心から...あなたはどのバージョンのSDDを使用していますか？

Answer 2

は

-doc-ソースは

の指定をmypackageとあなたのラインです '' 'myPackage'の代わりにそれを修正する必要があります（ソースパスと同じにしてください）

Answer 3

上記のような場合に、asdocで誤って生成されたパスを修正する単純なPythonスクリプトを書いています。つまり、メソッドmyMethod（v：MyClass、...）がある場合 asdocはリンクhref = "..を間違って生成します。/ スクリプトはこれを次のように置き換えて修正します：/

私が生成しているドキュメントはかなりフラットな構造、つまり一連のクラスを持つ単一のパッケージです。修正プログラムは、より複雑な文書構造で動作する場合、私は見当がつかない。

をとにかく、誰もがスクリプトを試してみたい場合、私はそれを送信するために喜んでいるよ。