「ローコード革命」(マイナビ出版)のハンズオンにコメント(リアクティブ編)

本全体のレビューは、「ローコード革命」(マイナビ出版)を読んでみました の方に書きました。

ここでは、書籍にまとまった初のOutSystemsチュートリアルである、この本のハンズオン部分について、初心者がつまずくかもしれない点にコメントしていきます。

シリーズ

検証環境

Platform Server (Personal Environment Version 11.9.0)

Service Studio (Version 11.8.9)

本は、電子版ver1.00

ハンズオンを始める前に

Personal Environmentの準備とIDEのインストールは手順に書いてありますね。

Service Studioを起動したら、環境に接続する必要があります。

画面上部の雲のアイコンをクリックしてSwitch Environmentダイアログを起動し、Personal EnvironmentのIdとパスワード(OutSystemsのサイトにログインするアカウントです)を入力して「LOG IN」ボタンをクリック。

また、企業内から試す人は、認証付きプロキシサーバーを経由することもあるでしょう。

その際は、Editメニュー > Preferences…を選択。以下のチェックボックスをオンにして設定してください。

アプリケーションとモジュールの関係(P.102)

モジュールが一般的な感覚で言うアプリケーションです。1塊の機能を作成する場所。

アプリケーションはそのモジュールを格納する場所です。つまりアプリケーション1つに対し、モジュールは複数個作れる。また、アプリケーションの種類によって作れるモジュールの種類も制約される。

ブートストラップの動作の仕組み(P.106 A.9)

ブートストラップすると

  1. DataセクションのResourcesフォルダに指定したExcelが登録される
  2. LogicセクションのServer Actionsフォルダにブートストラップ用Action (BootstrapCustomers) が作成される
    1. 登録したExcelから全データを読みだしてEntityに追加する処理
    2. 先頭でEntityの件数をチェックし、1件でも登録済みであれば実行しないようになっている
  3. ProcessesセクションにActionを起動するTimer (OutSystemsにおけるバッチ) が作成される
    1. Schedule「When Published」は文字通り、モジュールをPublishした時点で自動で起動されることを示す

Entityの型(P.114 B.1)

ここで作成するEntityのAttributeは、名前を入力した瞬間、正しい型がData Typeに設定されていると思います。

これは、OutSystemsの型推定の機能で、名前の一部が特定のパターンに一致していると動作します。

一覧:アトリビュート/変数のデータ型を推定する

CustomerIdは<Entity名>Idのパターンに当てはまっているため、Customer EntityのIdがデータ型になるのです。ちなみに、Entity Idは通常Long Integer型ですが、他のEntityや変数でこのIdを型として扱う場合、「<Entity名> Identifier」という型として扱います。

こうすることで、その型に入っている値は、該当Entityの識別子であることが明確になりますね。なお、OutSystemsのEntityが持つ主キー(Id)は常に1つです。

GetOrders.List.Current.Orders.Idの意味(P.118 C.4)

「GetOrders」は、スキャフォールディングによって作成されたAggregate (Entityのデータを検索するツール)につけられた名前です。以下の部分。「GetOrders.List」で、Aggregateで取得した結果のリスト(SQLの検索なので通常は複数なのでリストになる)。

List.Currentはそのリスト(同じ型の複数件のデータを順に並べたもの)をループで処理するときに、現在の位置のデータを示します。この場合、画面にテーブル表示しているため、各行に表示する1件ということ。

OrderId <> NullIdentifier()(P.124 C.17)

「<>」記号は、左側の値(変数OrderId)と右側の値(NullIdentifier())が「等しくないなら」という条件を表します。

「NullIdentifier()」は、組み込みの関数で、EntityのIdの値が未入力であるときの値を返します。

つまり、この条件は「画面引数OrderId(画面の編集対象を表す)が未指定でない=指定されている=既存注文の編集の場合」を示す。

ちなみに、If WidgetはConditionに設計した条件が成り立つとき、Trueの側に配置したWidgetのみが表示され、成り立たないときはFalseの側に配置したWidgetのみが表示されるもの。

D.OrderにOrder Lineを追加するロジックの作成 (P.126- D)

一連の流れで引っ掛かりそうなポイントを順に。

まずこの処理ですが、前提として、

  • 1つの注文(Order)を表示/編集するのがOrder Detail画面
  • Order Detailは3つのパートに分かれている
    • 左上:対象注文の属性を表示/編集するフォーム(Order Entityの1レコード)
    • 右上:注文明細を追加するフォーム(OrderLine Entityの1レコード)
    • 下:対象注文に追加された明細を一覧表示するテーブル
  • OrderとOrderLineは、普段の買い物で言うと、1つのレシートがOrderで、その各行(コーヒーが1点のようなデータ)がOrderLine

で、このロジックは右上のフォームの追加ボタンを押したときの操作です。

Assign

変数に値を設定する要素。Variableの部分に編集先の変数、Valueの部分に設定する値を指定。

この例では、追加するOrderLine Entity用の値を一時保存するOrderLine変数があるので、そのOrderId属性に、画面で表示/編集対象としているOrderのId属性を設定しています。

CreateOrderLine Action

このActionは、Entity作成時に自動作成されるEntity Actionと呼ばれるものです。

OrderLine Entity型の変数に値を埋めて引数として渡すとDB内にレコードを追加してくれます。

ちなみに配置したActionの下辺に波線が出ていると思います。

これは、開発ソフトウェアが出している警告です。DB更新処理をセキュリティチェックをせずに、Client Actionから直接実行しているために発生しています。本来であれば、Entity Acitonを別のServer Actionにラップして、その先頭でセキュリティチェックを実行します。ここはチュートリアルなので、そのままにしてあるのでしょう。

Refresh Data

Aggregateを指定し、もう一度DBから再取得します。この場合は、追加した注文の明細(OrderLines)を含めた結果が表示されるはず。

なお、Reactive Web Appでは変数の値が変更されると自動でUIも変更されます。つまりAggregateが変更されたことで、画面下部のテーブルの表示も最新になる。

画面の「Anonymous」にチェック

その画面にアクセスするときに、ログインが不要になります。

Anonymousがチェックなしで、Registeredにチェックがついている場合、ログインが必要です。なおログインさえしていればよく、権限の種類は問いません。

WidthのN col設定について(P146-147, 7.2-7.5)

OutSystemsでは、ある領域の横幅を12列に区切ります(※)。Widgetを適当に並べた場合、各WidgetのWidthプロパティの横幅を全部足していって、12 colに達すると次の行に折り返します。

ここでは、1行を画像(4 col)とContainer(8 col)に設定しているので、Listの1項目の幅の1/3を画像、2/3をContainerと分けていることになります。

(※)この12の部分は実は設定で変更できるが、普通は変えないのでここでは置いておく