# Gourmet Recipe Manager - Spring Boot - Version 2
This is a port of Thomas Hinkle (thinkle) Gourmet Recipe Manager.
As explained in the original version, thinkle's original Gourmet Recipe Manager
desktop app has suffered frequently over the years by changes made to external
components that it depended on and unfortunately he has not had the time to
repair the the app after recent upgrades (including Python 3 and Gnome library) changes broke it.
Java is not only "write once/run anywhere", but also was designed for an environment
where changes should not break existing Java apps. Hence the port. It was easier
than trying to learn all the new external resources used by the Python version,
make detailed repairs and wait for it to break again.
## Functionality
This version of the system should provide all of the basic Recipe management functions, including adding new recipes, pasting in lists of ingredients, and managing
shopping categories. The ultimate intent is to provide all functions that the original Python app did.
## Building the app
You must have Maven installed on your system to build a copy of the app
from scratch. You must have Java 11 or later installed on your
system to run Maven and to run the app.
This project can be built on the command line using the
``mvn clean install`` command if you have Maven installed in
your PATH.
Note that the first time you run Maven, it may download a lot of
data from the Internet. This data will be cached by Maven so
thereafter, you will not need an Internet connection unless
there are changes to the app.
## Running the app
This project can be run from the command line by using the
``mvn spring-boot:run`` command. Or do an install build and
use the JAR file that Maven builds in the ``target`` directory.
for example:
```
java -jar target/gourmetj-0.1.1-SNAPSHOT.jar
```
The actual JAR name will vary depending on the build version.
You can copy this jar to any location you prefer.
You must have a recipe database file (see below) to store the
recipes in. By default, it will be looked for in your
home directory.
As of the 0.1.4 release, the parts of the application that can
alter the database are now password-protected. You will need
a ``.gourmetpw`` file to contain your userid/password
definitions. By default it should be in the same directory
that you are running the application from. A sample password file
is included in this project.
To actually access the application, open your web browser
to ``http://localhost:8080``
## Database
This product uses the same database as the Python-based version
of the system, which is a SQLite3 database named ``recipes.db``.
At the moment this app cannot build a database from scratch,
so you must use an existing copy of a ``recipes.db`` file.
## Note on JavaServer Faces
The Spring Boot version supersedes a previous port based on the Apache Tobago JSF tag library. It uses the PrimeFaces JSF tag library, as presently that platform has better Spring Boot support. Plus Tobago is quite different from most of the
extension tag libraries to the point where it almost isn't JSF.
## New in Version 2.0
### Database change
The backing database as defined in the project is now MySQL
instead of SQLite. The SQLite JDBC driver may have been a bit
casual about a few things compared to MySQL. The JPA should work
for either database now, although it should be noted that SQLite
isn't really intended for multi-user webapps and should only be
employed when you run this app on your local desktop.
### Improved graphics support
A lot of recipe websites publish images in webp form. Support
for webp has now been added.
### Better session management
JSF tends to depend on session-scope context. Sessions, however
time out and this has been an annoyance when a recipe is being
displayed. To minimize this, better timeout mechanisms have been
installed and the recipe browser keeps last-search and search-type
values in long-lived cookies on the client. The server will read
and cache them, but if the server times out, it will automatically
re-read the cookies on the next request.
When editing, the AJAX controls tended to get confused when a
session timed out. New changes give a "save work" warning 5 minutes
before timeout, and force a timeout from JavaScript that
exits the unattended page before the user can run afoul of the
lost session.
Note that by default, JSF caches ViewState in a session so every
JSF View can cause a session to be created, not just Views that
reference View- or SessionScoped backing beans. This is alterable
by setting an option in the faces-config.
force
### Developer/deployer note. Because of caching, updated installations
may not render properly. Manually request the "/main.xtml" resource
and that should flush out stale info being used by "/main.jsf".
Followup: Excess payloads were being added to the welcome page
that caused HTTP "400" errors fetching resources. A fix has
been made, although the ultimate solution will probably be more
JSF-friendly.
