Userテーブルのデータを削除するプログラムを作成しました。
いわゆるCRUDのD（delete）の部分です。
今回は、画面遷移を掲載します。
次回は、MVCの全体の構成と関連の概念図とプログラムコードを掲載する予定です。
以下が画面遷移です。
次回、DELETE機能に関するMVCの全体の構成の概念図とD（Delete）機能に関連するクラス、スクリプトファイルのコードを掲載します。
蛇足ですが、
モデルケースの作成を検討する段階で、Viewの部分の作り込みを楽にするために、PEAR（PHP Extension and Application Repository）のHTML_QuickFormとSmartyを使うことを検討しました。
（たまたま、購入した本で紹介していたため・・・ちょっと古い本です）
しかし、PEARには色々問題があり、使えないことが判明しました。
次のような問題点があります。
一般的な使用：PEARは依然として利用されているライブラリが存在しますが、新しいプロジェクトや最新の開発環境ではComposerが推奨されることが多いこと。
つまり、PEARはもう古いということ。
バージョンの組み合わせ：PEARパッケージの中には、特定のPHPバージョンに依存しているものがあり、PHPのバージョンアップ時に互換性の問題が発生する可能性があること。
PHPのバージョンアップができなくなる可能性がるということ。
最新のPHPバージョン：一部の古いPEARパッケージは、最新のPHPバージョンで動作しない場合があります。特にPHP 7.x以降では、多くの非推奨機能が削除されていること。
つまり、最新のPHPバージョンでは使えないということ。
検討段階で、インストールやサンプルプログラムを作ったり、色々試行錯誤して、結局使えないことが分かりました。
2、3日、無駄な試行錯誤をしてしまいました。
現在は、Composerが推奨されています。
以下のような利点があります。
柔軟なバージョン管理：Composerは柔軟なバージョン管理が可能であり、異なる環境でも簡単に互換性を保つことができます。
依存関係の管理：Composerは依存関係を自動的に解決し、プロジェクトに必要なパッケージを簡単にインストールできます。
広く利用されている：現代のPHP開発において標準的なツールとして広く普及しており、多くのライブラリがComposer対応しています。
今回のレシート管理プログラムでは、Composerを使用しないで、PHPだけで作成します。
PHPだけで作ってみて、今後新たなWebシステムを作るときにComposerを使ってみようと思います。
PHPだけで作ってみないと、Composerのメリット、デメリットが分かりませんから。
