詳細ページ要項

ジャンルページのワイヤーフレームを少し書いてみただけで、あれこれと必要なものが見えてきました。

ログの削除
ログの編集
ジャンルの削除
ジャンルの編集

ログの削除ですが、これはdeleteカラムをテーブルに入れてないので、恐らく物理削除にするしかないと。
ここから修正を加えると、大規模改修になるので、現状は諦めます。

編集ボタンなのですが、これも一括で編集できるようにするとなると、思いの外、手間が掛かりそうなくらいの記述をせねばならないです。
これは覚悟しておこう。

ログIdからデータと照らし合わせて、変更があったがIdのデータを更新する作業。
それとも、一度、表に出力されているデータ全てを更新させるか？

その方が記述は楽だろうけど、何百件、何千件ともなるとデータ量が...…。
一方、一つずつ紐解いて更新があった物のみだと裏の負荷が大きいかもな...…。

ジャンルの削除に関しては、ログごと消えてしまう未来しか見えないし、そうなると他のテーブルに残されたデータの扱いはどうすれば良いのだろうか？
これに関しては深く考えないと、消えたジャンルの書籍の情報だけ残ったりしてしまうエラーが見えてきます。

関連するデータを全て抹消する事は、そもそも必要なのだろうか？分からないけど、取り敢えず出来た方が良いのでは？

ジャンルの編集はジャンルの名前を変更したり出来れば良いな、と軽く考えていたのですが、例えばプログラミング設計を既存のプログラミングという名前に変更したい場合、ユーザーIdから照らし合わせて、ジャンル名が存在する場合と存在しない場合の分岐処理させて、それぞれ長ったらしいSQL文を作らなくてはならない。

ただただ出力するだけのページのつもりだったのに、本当のゴールがもっそい遠いところにあったので、茫然自失です。

一括でどうにかしようと考えてるから難しいのか？単体ログ毎だったら、また新しいページに移動させて、そこでじっくり編集させることは出来ると思うのですが。

ワイヤーフレームに着手した瞬間に課題の片鱗が見えてきたのは良いけど、恐らくこれは氷山の一角でしょうね。

開発を進めていく内に、もっと課題が見つかると思われます。

本当に簡単に考えてた分、圧倒されちゃいました。書籍に関しては、もっと多くの機能が必要になりますので。
例えば、読了の切り替えトグルボタンとか...…。もっと嫌んなっちゃうのです。

なので、今日はジャンルだけを考えるようにしよう。ロジックは後で考えるようにしよう。

あ、そう言えば、メインページの時間入力ボックスはボタンで時間を0.5ずつ増減させているのですが、手入力した際に、どのような挙動になるのか？調べないと。

単純なアプリなのに、あれこれが大変です。