Code for final

ふぁいなる向けのコード置き場です。すでにコードじゃないこともいっぱい。

intra-mart(accel)でポップアップ画面を表示したときスクロールバーが出る問題。

intra-mart

intra-mart Accel Platformではポップアップ画面は非推奨ですが、エンドユーザから昔ながらの操作性を維持したいということでポップアップを希望されることもあります。

その場合、window.open()でaccelの画面を指定して開くと思いますが、何故かスクロールバーが出ます。

これはなぜかというとaccelのテーマは縦と横の最小値が定義されているからです。

こういう場合は以下のようにCSSをオーバライドしましょう。

<style type="text/css">

  #imui_container {
    min-height: 0 !important; /* imの高さ指定を無効化 */
  }

  body {
    min-width: 0 !important; /* imの幅指定を無効化 */
  }

</style>

これでスクロールバーは消えます。

intra-martでルーティング追加したあと再起動してログインしただけなのに500エラーが出て詰んだとき。

intra-mart

accel開発経験者なら必ずあるのではないでしょうか。

  • メニューに新しい画面を追加して、ルーティングを追加して再起動してログインすると500エラーになって何もできなくなること。

  • ほかの人からメニューをもらってインポートしたあとトップページを表示したら500エラーになって何もできなること。

こういう場合は、たいてい認可リソースが不足しているのが原因です。
認可の仕組みをよく理解せずにてきとーにリソースURIを書いてしまったときに起きます。
認可リソースURIをルーティングに書くときはまず、認可の画面から先にリソースを作成しておく必要があります。

コンソールに不足している認可リソースが以下のような感じで出ていると思います。

Caused by: jp.co.intra_mart.foundation.authz.services.ResourceNotFoundException: [E.IWP.AUTHZ.DECISION.10007] リソースグループが登録されていません。 URI = service://sandbox

認可画面からリソース追加するかーとテナント管理者でログインすると500エラーが…
なんと、こうなったらテナント管理でもログインできなくなります。管理者なのに。

じゃ、システム管理者かーと思って、管理者のメニュー見ても認可はありません。
詰んだ。
という状況になります。
これで環境を作りなおしたひともいるんじゃないでしょうか。

ではこういうときどうするかというとテナント管理者でログインした後に以下の認可のURLを直接たたきます。

http://localhost:8080/imart/tenant/authz/settings?imui-theme-builder-module=headwithcontainer

社内のimに詳しいひとに教えてもらいました。
単純に認可の画面のpathだけたたいてもだめです。テーマのメニュー表示を無効にしないとメニューをロードするので結局500エラーになります。
こんなん普通のひとはわからないですよね。

こんなこともあるので新しい画面を作ったらメニューに追加するのは最後の最後をおすすめします。(開発中はURL直打ちのほうが早いです)
あと開発中の認可は"welcome-all"でいいと思います。

これで解決できるとは言え、メニューを表示するときそのメニューの認可リソースがないからってログインできなくなるのは横暴な気もしますが。テナント管理者はログインできるようにするか、メニューに表示されないくらいにとどめておいてほしいものです。

intra-martのWeb Platform開発経験者がAccel Platformで開発する際に学習したほうがいい８つのこと。

intra-mart

ついこないだまでやってたプロジェクトがintra-mart Accel Platformでの開発の初体験でした。
そしてまた違うプロジェクトになったのでまた戻っても忘れないようにいろいろと気をつけることをメモってこうと思います。

intra-mart Accel Platform(iap)といって名前が大きく変わってますが、スクリプト開発する場合はそれほど大きくは変わらないので安心してください。（JavaEEはあまりやったことがないのでわからない）

僕も実際開発するまでいろいろと変わってるんだろうなー覚えるの大変そうだなーと思ってたんですけど、実際やってみるとコードを書くという点で言えばびっくりするほど何も変わりません。
htmlとjsを用意してinit()に初期処理を書くだけです。

コードを書く点以外のプラットフォームとして変わっているところもいろいろとあります。
以下にiwpと違う点を書きたいと思います。 iwp開発経験者は以下の点を重点的に学習するとiap開発スキルが身につくと思います。

1. ルーティング

いままではサーバにディレクトリ構成に応じた独自のパス(page)を元に定義していたのでurlがものすごい長くなったりしていました。これを解決するためにディレクトリ構成に影響せず仮想的に定義できる(path)という概念が導入されました。 pathに応じてjsに定義した関数(action)を呼び分けるってことも可能なのでいままでformにactionで指定していたことがpathだけで定義できるのは便利になりました。

そのpageとpathとactionの紐付けを記述するのがルーティングファイルです。WEB-INF/conf/routing-jssp-config におきます。
ただし、これにルーティングを加えたら再起動しないと反映されません。開発時は地味にめんどいです。

ルーティングの考えは最近のWEB開発フレームワークでは普通にあると思います。ただ、ほかのフレームワークにあるHTTPメソッドによるルーティングはないみたいです。 そしてルーティングには認可も定義します。（認可については次で）

学習するドキュメントは↓
ルーティング — スクリプト開発モデル プログラミングガイド   第16版 2020-04-01   intra-mart Accel Platform

2. 認可

この認可というものがiap開発の最大の難所だと思います。
いままではメニュー設定にロールを設定するだけで権限周りはいたってシンプルでした。
その反面、複数の権限の人が画面を使う場合は、使う人によってメニューを分けたりしないといけませんでした。
その対策として登場したのが認可です。

認可はユーザのアクセスをユーザが保持しているロール、組織、パブリックグループ等に応じて許可／拒否を行うだけなのですが…
この認可、もの凄く細かいところまで定義ができたり、継承ができます。はっきり言って高機能すぎです。ほどんどの開発ケースではオーバースペックだと思います。 そして難しい用語がいっぱいでてきます。（ポリシー、リソース、リソースグループ、サブジェクト）これらがどう関係しているのかいまだに理解できていないです。というか実際の開発をしながらこれらを理解する時間はとれないです。
im社以外にこれをほんとに使いこなしているベンダーは果たしているのか疑問です。

とは言えシンプルに使うこともできます。たいていは画面ごとにリソースを定義して認可の画面でポチポチするだけでOKだと思います。
ルーティングと違ってリアルタイムに反映されるのがいいですね～。

だだし、新しい画面を作成してメニューに追加したけど、認可とルーティングの整合性が合わなくなるとログインできなくなったりするので注意してください。（これについては以下のエントリーを確認してください）

final.hateblo.jp

学習するドキュメントは↓
認可 — スクリプト開発モデル プログラミングガイド   第16版 2020-04-01   intra-mart Accel Platform

3. テーマ(PageBuilder)

iapからフレームではなくなったこともあり、メニューの表示制御はPageBuilderによって行われます。
このことを理解していないとポップアップを表示するときにメニューがついてきたりしてびっくりします。

ポップアップに使用する画面はconf/theme-head-with-container-path-config でpathを指定したりしないといけないです。
そもそもiapではポップアップは推奨されていないみたいです。imuiPageDialogを使って、ライトボックスっぽく表示するのがいいみたいです。

学習するドキュメントは↓
http://www.intra-mart.jp/download/product/iap/im_ui/im_theme_specification/texts/components/PageBuilder.html

4. eBuilder(ユーザモジュール)

いままで開発したものは綺麗にパッケージングできませんでした。iapからはユーザモジュールという形でパッケージングできるようになりました。immファイルというただのzipですけど。
これに伴い、eBuilderの開発でのファイルの配置の仕方とかも大きく変わりました。
eBuilderについては以下のエントリーを参照してください。

final.hateblo.jp

im社のセミナーでは、このモジュールという概念を導入したことで正しい方法で製品カスタマイズをすることでバージョンアップも可能であるとうたわれていましたが、実際そんなプラグインで対応できるレベルのカスタマイズが要求されることはなく、このボタン消してほしい、この製品画面にこういう機能を追加してほしいとかっていうエンドユーザが多いのでそんなに変わっている気がしません。

5. SessionScopeStorage

その名の通り、セッションが生きている間のみ有効なストレージです。これが追加になりました。
ストレージと扱い方が同じでAPIの名前が違うだけなので簡単です。そして一時ファイルとかを出力する場合にとても使えます。
若干、APIの使い方が変わっています。

Storage — スクリプト開発モデル プログラミングガイド   第16版 2020-04-01   intra-mart Accel Platform

6. 外だしSQL

MyBatisっぽいアレです。文法は特殊ですけど、条件分岐とかもできます。
コードにSQLを書かなくていいのでコードがスッキリします。

学習するドキュメントは↓
データベース — スクリプト開発モデル プログラミングガイド   第16版 2020-04-01   intra-mart Accel Platform

7. API

APIはいろいろ変わっています。
特にクライアント側の画面周りはimuixxxxを主に使うことになると思います。
サーバ側はIM共通マスタのままなのでそんなに大きく変わらない気がしますが、非推奨のAPIも増えています。
とはいえ、たいていはAPIドキュメントを見ながら開発すれば問題ないと思います。

intra-mart Accel Platform API Documentation

あとiwpから移行の際は互換モジュールをいれればほとんどiwpと同じように動作しますが、中には互換で動かすとfalseを固定で返すという地雷もあるので以下の互換表をよく確認することをおすすめします。

intra-mart Accel Platform - Web Platform API互換対応表

8. テナント

ログイングループの代わりにテナントという概念が導入されました。
大雑把にみてログイングループと変わりはない気がします。
いちいちログイングループ管理者用のログイン画面からログインしなくてもユーザとかをいじれるようになったのは便利になったと思います。

とまぁ上記の8点をおさえておけばiwpしか経験したことがなくてもaccel開発できます！と言っても過言ではないと思いたい。