1

私はかなり抽象的なツリー描画システムを作成していますが、必要なすべての描画機能を形式化するのに非常に苦労しています。残念ながら私の検索は無駄だったので、誰かがこのトピックについて読むべきものを私に指摘してくれたらとてもありがたいです.

木を表示するためのメタ言語を探しています/作成しようとしています。これらのツリーでは、各ノードは、ユーザー定義のグラフィカル表現を持つユーザー定義オブジェクトのインスタンスです。

各オブジェクトは、グラフィカルな表現である名前に関連付けられており、有限数の子 ( 0+ ) を持ち、オブジェクト自体であることが知られています。オブジェクトの再帰は許可されていません。各オブジェクトには、(ユーザー定義の方法で) グラフィック表現を変更する条件をトリガーするために使用されるユーザー定義のオプションがあります。一部のオプションは自動的に適用されますが、他のオプションはユーザーの操作が必要になる場合があります (「このオブジェクトを A または B にしますか?」)。これにより、オブジェクト ツリーをインスタンス化する必要がある理由が説明されます。

Object
    Name                // The Object Name
    Childs              // List of Object Childs
        ContextName         // The Name of the Child within this context
        Types               // List of Objects' names. This child may be only one of them. Decided by the user during instancing.
        Options             // List of Options assigned to this child. Some of them may require user interaction, and apply other Options to the Child's childs.
        *Priority           // This is an integer which is used to decide the order in which childs are drawn.
    Symbol Name         // The Graphical representation of the Object

オブジェクト ツリーがインスタンス化されると、常習的なユーザー入力なしで描画する必要があり、ここで問題が発生します。オブジェクト ツリーのインスタンス化により、各オブジェクトに特定のグラフィック表現が割り当てられます (これを Symbol と呼びましょう)。ただし、割り当てはインスタンス化の前にはわかりません。異なるオブジェクトが同じシンボルを持つこともあり、オブジェクトのオプションに応じて異なる方法で描画される場合があります。

このため、シンボルはオブジェクトとは別に定義する必要があり、ユーザー指定の規則に従って、シンボル自体 (および割り当てられた子) を正しく描画できる一連の抽象メカニズムが必要です。

各シンボルは、画像 (または画像なし) と有限数の添付ファイルによって表されます。アタッチメントは、オブジェクトの子のシンボルを描画する場所を描画コードに指示する、シンボルの座標に対する相対位置です。それらのそれぞれには、使用される特定の条件があります (たとえば、このアタッチメントは、特定のオプションを持つシンボルによってのみ使用されるか、または N 個のシンボルが既に描画されている場合、既に描画されたシンボルとの衝突がないなど)。

アルゴリズムは、優先度によって指定された順序に従って、各オブジェクトの子に対して空きの添付ファイルを見つける必要があります。子の添付ファイルを見つけることができない場合、ユーザーは自動再試行を許可するルールを事前に指定できますが、それらも失敗すると、ツリーの描画全体が失敗します。これらのルールのいくつかは、中毒性のある子シンボルを追加したり、子シンボルを他の子に割り当てたりする (それらを grandChildren にする) などを許可します。

Symbol
    Name
    Main Image      // Image Path, Height, Width
    Attachments     // List of the attachments, their position, requirements and addictional infos
    Fail Rules      // List of actions to do if it is not possible to successfully assign each Child to an Attachment

私の主な問題は、Symbol がアクセスできる変数の数がかなり多いことです。各シンボルは、このメタ言語を使用して定義する必要があることを再度思い出しますが、その子シンボルの情報にアクセスできる必要があります (デッドロックや循環参照を避けるために、他のシンボルにはアクセスできません)。すべての子のシンボルの高さと幅の合計に等しいシンボル、または同じ画像を使用するシンボルなど。これは、ユーザーがシンボルのルールを最終的な構造とは別に記述することにも起因します。

同時に、ツリーは上から下に描画する必要があるため、これらの情報の一部は最初から利用できない場合があり、大量のバックトラックが必要になる場合があります。

また、これらはすべて、形式化して解析できるメタ言語内で定義する必要があるため、言語に最大限の自由度を与えるためにメタ言語が必要とする機能を定義する必要があります。過度に複雑にならないように user を記述します (これはあいまいな制限ですが、基本的には Tikz をメタ言語のサブセットとして使用したくありません)。しかし、私はそれらを特定するのにかなり苦労しています。

前に言ったように、この種のトピックや、このようなプロジェクトを完了する方法についての情報を探しています。メタ言語を完全に完成させることができれば、コードを実装してこれらすべてを実行するのにそれほど問題はないと思います。私の問題はほとんど理論的なものです。

4

2 に答える 2

0

私は階層データを使っていくつかの同様のプロジェクトを行いました。私が始めた場所をあなたに示します:

ジョーセルコはツリーデータの王様です。彼の本から始めることをお勧めします。これは、ロジックとビジネスケースの組み合わせです。SQL for Smartiesのツリーと階層には、新しいエディションもあります。そこには階層を記述するための言語もあります。

私は、ツリーデータをプルして保存するための非常に効率的なシステムを備えた階層を保存するためにOracleを使用しました。ドキュメントまたは本のいずれかで「接続方法」を検索してください:MishraとBeaulieuによるOracleSQLの習得。

ポインタを使用してサーバーから画像をプルし、データベースに保存しないようにすることができます。グラフィカルオブジェクトを使用したデータの階層表示を使用するいくつかのシステムを構築しました。これにより、オーバーヘッドがこのように抑えられます。DevExpressとTelerikはどちらもツリーを表示するための優れたビューアを備えており、私は次のレベルを動的に構築しています。ドリルダウンするまで、次のレベルがいくつになるか、または何になるかはわかりません。これらの例を試してドキュメントを読むと、すぐにこれをまとめることができます。

telerikの場合、このリンクは複数のロードオンデマンドビューを表示します:http: //demos.telerik.com/aspnet-ajax/treeview/examples/programming/loadondemandmodes/defaultcs.aspx

Devexpressの場合:http: //demos.devexpress.com/ASPxTreeListDemos/Data/VirtualMode.aspx

于 2012-05-24T19:46:14.757 に答える
0

HTML/DOM で考えてください。

私が使用しているアウトライナー NoteCaseのファイル形式がプレーンな HTML であることを知ったときは驚きました。NoteCase はここにあります: http://notecase.sourceforge.net/index1.html

なじみのない方のために説明すると、アウトライナーはアプリケーション タイプであり、主にテキスト ノードを階層ツリーで編成できます。タスクアウトライナーもあります。アウトライナーにグラフィカルな表現がある場合、それはマインド マッピングと呼ばれます。とにかく、ファイルシステムのディレクトリ構造も概略です。さまざまな分野のアウトライナーがたくさんあります。詳細については、ウィキペディアを参照してください。

Notecase は DL/DT/DD を使用します。DL はリスト、DT はアイテム、DD はアイテムの説明です。もちろん、ネストすることもできます。

  1. フォーマットが HTML の場合、人間の目で読みやすいようにブラウザで表示するには、CSS のみが必要です。

  2. 追加のプロパティがある場合は、追加のタグまたは属性を定義できます。これらはブラウザーには表示されませんが、レンダラーには表示されます。

  3. ソース HTML ファイル形式をより詳細な HTML 形式に変換するコンバータを作成する必要があります。この形式には、計算フィールド (サブノードからの値の合計、またはサブノードの「継承」マークを継承されたものに置き換えるなど)が含まれます。親ノードからの値)、いくつかの追加の書式設定、または属性を HTML ノードに変換できます。

    <node type="x" size="y" />

    <div class="node">
      <div class="param"> type: x </div>
      <div class="param"> size: y </div>
    </div>

  4. あなたのデータ表現は一種の DOM であり、同様の方法で処理する必要があります。まず、ファイルから値を解析して読み取ります。次に、追加のラウンドを実行して (ツリーをたどって)、欠損値をデフォルトで埋めたり、継承された値や要約された値を計算したりする 必要があります。標準の DOMパーサー

    は使用できないと思います。どのDOMモデルが実際にはサポートしていません。

  5. 実行したい操作と同じ数だけオブジェクト ツリーたどることを恐れないでください。パスの順序を変更したり、パスを有効または無効にしたりして遊ぶことができます...機能が増えるにつれて、新しい処理パスとして明確になります。

    複数回実行する必要があるパスがある場合があります。たとえば、1 つのパスで値を計算できない場合 (そのソースを最初に計算する必要があるため)、「まだ実行していません」というフラグが返されることがあります。 「変更なし、完了しました」という結果になるまで、ツリーで再度実行します。

私はあなたを少しプッシュしたことを願っています。

于 2012-05-24T20:18:40.840 に答える