ローコード開発プラットフォームを実現するためのステップバイステップ - ローコード構成モジュールビュー機能の全体設計

バックグラウンド

前回の記事では、インターフェイス プラットフォームの統合、アーキテクチャの最適化、ローコード構成モジュール、エンティティ、モデルの使用について紹介しました ( https://blog.csdn.net/seawaving/article/details/130642577 )。今日も続きます前回の記事では、全体設計の底面図の紹介を中心に書きました。

実際にはフロントエンド Web ページであるビューは非常に複雑です。

以下の図に示すように、まず全体的なフレームワークと手順を確認しましょう。

プラットフォームの運用

エンティティ リスト行の [構成] ボタンを使用して、エンティティ構成機能を開くことができます。左側のナビゲーションで [表示] リンクをクリックすると、右側にビュー リストが表示されます。このページには、追加、変更の機能が含まれています、ビューの削除、クエリー、および表示。次の図に示すように
画像.png
、[追加] をクリックしてビューを作成します。
画像.png

プロパティを表示する

上の図に示されているように、ビュー属性はそれほど多くはありませんが、すべて重要なものなので、以下で詳しく説明します。ただコンセプトがわかりにくく、なぜそうしなければならないのかが明確ではないため、具体的な事例やシナリオと組み合わせて設計や実装のアイデアを紹介します。

ビュータイプ

さまざまな目的に応じてビューが分類され、モデリングにより次のタイプのビューが生成されます。

  • リストビュー
  • 新しいビュー
  • ビューを変更する
  • ビュービュー
  • ツリー表示
  • ツリーテーブルビュー
  • 参照ビュー
  • ツリー参照ビュー
  • ツリーテーブル参照ビュー
  • マスタースレーブビュー(実装予定)
  • カスタムビュー(実装予定)

インターフェイス プラットフォーム モジュール下のアプリケーションなど、単一のモデルに対応する通常のエンティティの場合、リスト ビュー、追加ビュー、変更ビュー、および共通のクエリ、追加、変更、および表示ページ (削除) を含むビュー ビューに対応します。機能はページではなく、リスト ページにある機能ボタンのみです)。
画像.png
組織などの自己関連付けされたエンティティの場合、リスト ビューが単なるテーブル タイルである場合、階層関係を示すのが難しく、直観性が低くなります。このとき、左側にツリー、右側にリストというツリーテーブルビューが必要になりますが、実際にはツリーテーブルビューはツリービューとリストビューからなる複合ビューになります。

参照ビューは、他のエンティティ関連付け属性に使用される選択ページであり、ユーザーが組織を指定する必要がある場合は、一般参照、ツリー参照、ツリー テーブル参照の 3 つのタイプに分類できます。

一般的な参照: インターフェイス プラットフォームでアプリケーションのデータ権限を構成する場合は、アプリケーションを選択する必要があります。参照ビューに対応するデータ リストで十分です。
画像.png
ツリー参照: ユーザーが保守する場合、組織構造を選択する必要があり、ツリー参照ビューに対応するツリーが必要です。

ツリー テーブル参照: ユーザーを選択する場合、左側のツリーと右側のテーブルが必要です。左側は組織ツリー、右側はユーザー リストで、ツリー参照ビューに対応します。ツリー参照エンティティは実際には、ツリー ビューとリスト ビューを組み合わせた複合ビューです。

また、プラットフォームについては計画されているがまだ実現していないという 2 つの意見があるので、ここで言及しておきます。
1 つはマスター スレーブ ビューで、受注などの主従関係のエンティティにはマスター スレーブ ビューが使用されますが、これは実際にはツリー テーブル ビューに似ており、複合ビューでもあります。
2 つ目はカスタム ビューで、一部の個人用ページに使用され、標準化された方法で構成することはできません。ネイティブ開発によって実装され、指定されたパスがシステム全体に組み込まれます。

ソリッドモデル

ビューに対応するエンティティ モデル。ビュ​​ーのデータはエンティティ モデルから取得されます。エンティティには複数のモデルがある場合があるため、現在のビューに対応するモデルを指定する必要があります。次の図は、実際には一般的なモデルの例です。参考ビュー。
画像.png

名前、コード

名前、つまりビューの名前は、デフォルトではビュー タイプの名前と同じですが、必要に応じて調整できます。
エンコーディング、つまりビュー エンコーディングは、デフォルトでビュー タイプ エンコーディング変換によって生成されます。ビュー タイプはプラットフォームのデータ ディクショナリを通じて実装され、その命名は一定の命名スタイル (すべて大文字、単語の区切りにはアンダースコア) で、エンコーディングはフロントエンド vue ページのファイル名に対応し、小さい文字列を使用します。こぶがあるため、変換して生成する必要があります。変換はフロントエンドの実装で行われます。

プラットフォームのこの部分には、コード生成部分におけるきめ細かい制御がありません。たとえば、リスト ビューでは、コードは追加ビュー、変更ビュー、およびビュー ビューとして自動的に導入されます。コードの名前を変更するには、コード生成後に手動で調整する必要があります。したがって、コードを自由に変更することはお勧めできませんが、次のとおりです。デフォルトの規則。

初期化前、初期化後

ビューのロードの前後にメソッドをフックし、js メソッド本体を記述するだけで、プラットフォームはコード生成リンクのフロントエンド処理システムでそれを処理します。前処理は、主にパラメータの受け取り、デフォルト値の設定などに使用され、すべてに適用されます。ビュー。

たとえば、ユーザーリストビューから、左側の組織ツリーで財務部門ノードを選択した後、追加ボタンをクリックして新しいビューを開きますが、このとき、現在選択されている組織IDを自動的に入力したいとします。
画像.png

画像.png
これは、新しい操作が最初にバックエンド エンティティ サービスの init 操作を呼び出し、新しいオブジェクトを作成し、返されるデフォルト値を設定するため、初期化後にここに配置されます。初期化前に配置された場合、組織 ID は上書きされます。

データ検証

データ検証フック メソッド。js メソッド本体を記述するだけで、新規ビューと編集ビューに適用でき、複合データ検証に使用されます。単一の属性を検証する場合、空にすることができない場合は、フォームのルールを通じて直接設定できます。ただし、複数の属性を連携させる場合は、このメソッドでデータの検証を行う必要があります。

たとえば、ボタンを構成するときにボタンに確認が必要な場合は、確認情報を入力する必要があります。これには、confirmFlag とconfirmMessage の 2 つの属性が含まれます。

 // 需要确认情况下必须输入确认信息
  if (this.entityData.confirmFlag === this.$constant.YES && !this.entityData.confirmMessage) {
    
    
    this.$message.warning('请输入确认信息')
    return false
  }
  // 需要控制权限则必须输入权限编码
  if (
    this.entityData.permissionFlag === this.$constant.YES &&
    !this.entityData.permissionCode
  ) {
    
    
    this.$message.warning('请输入权限编码')
    return false
  }
  return true

保存前、保存後

データ保存前後のフックメソッドは、ビューの追加や編集に適したjsメソッド本体を記述するだけです。プラットフォームはコード生成プロセスを処理し、それをフロントエンド処理システムに置きます。前処理は主に、保存前のデータの処理と保存後のロジックのトリガーに使用されます。

メソッドトリガー

ビューには 5 つの属性があります。初期化前、初期化後、データ検証、保存前、および保存後、これらはすべて、パーソナライズされたロジックと機能を実現するためにプラットフォームのフロントエンドによって予約されている拡張ポイントです。 ?
フロントエンドはミキシングに minx テクノロジーを使用します。

    // 初始化,参数可为空
    init(param) {
    
    
      if (this.beforeInit) {
    
    
        this.beforeInit(param)
      }
      this.api.init().then((res) => {
    
    
        this.entityData = res.data
        if (this.afterInit) {
    
    
          this.afterInit(param)
        }
        this.visible = true
      })
    },
    // 保存
    save() {
    
    
      if (this.beforeSave) {
    
    
        this.beforeSave()
      }
      this.$refs.form.validate((valid) => {
    
    
        if (valid) {
    
    
          if (this.validateData) {
    
    
            // 数据验证通过后才执行保存操作
            if (this.validateData()) {
    
    
              this.saveData()
            }
          } else {
    
    
            // 无需数据验证,直接执行
            this.saveData()
          }
        }
      })
    },

今日はここでやめて、次の記事でさまざまなタイプのビュー構成について説明します。

開発プラットフォーム情報

プラットフォーム名: One Two Three Development Platform
概要: エンタープライズレベルの総合開発プラットフォーム
設計情報: csdn コラム
オープンソースアドレス: Gitee
オープンソースプロトコル: MIT は
お気に入り、いいね、コメントを歓迎します あなたのサポートが私が前進するための原動力です。

おすすめ

転載: blog.csdn.net/seawaving/article/details/130764669