Documentation

Welcome to the Ancient Graffiti Project! As you may have noticed this project is massive and can be a little intimidating at first, we ran into this problem as well and created this guide to help you out. While we try to give a good overview of the whole project, we're still discovering new things so feel free to correct and/or augment this guide with your knowledge. Best of luck

The databases are postgresql, to get easy access to them just ssh into fred and then navigate to whatever version of the database Sprenkle gave you access to. For a full list of databases go into [documentation/graffiti_schema.sql](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/documentation/graffiti_schema.sql)

The setup process is fairly simple, in the setup folder the populate database class runs and calls a set of functions that populate the databases either directly by pulling data from csv files or indirectly by pulling data from other databases. <b>Note that populate database does not run on the startup so you'll have to call any setup functions manually for testing.</b> There's also a great guide to set up in [documentation/SetUpData.txt](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/documentation/SetUpData.txt)

Beans are java objects that encapsulate data taken from the database. In this project, beans are used to provide quick, easy, and controlled access to data pulled from a database. They tend to not do a lot of processing and really are just used for access.

Beans are generated by rowmappers. Rowmappers take the results from postgresql queries and turn them into beans using the constructor interface specified. Different beans are generally used for different queries and provide different interfaces. Rowmappers don't have to return beans though and can in fact just be used to map specific datatypes.

DAOs (data access objects) store and execute postgresql queries and handle all the errors that can come from such requests.

Web pages are all stored in the WEB-INF folder and are all jsp files. It is common to break up a page into a series of imports such that the page itself can basically be run in two lines. The imports contain all the structure of the page and allow for a consistent look. Check out [termIndex.jsp](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/src/main/webapp/WEB-INF/jsp/termIndex.jsp) and [termIndexList.jsp](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/src/main/webapp/WEB-INF/jsp/termIndexList.jsp) for an example.

Jsp sites are accessed through controllers. For each site that can be accessed their is an associated mapping in a controller that runs a function when the associated url is executed. These can be very short and just return the page or they can contain a lot of processing and data storage for the resulting web page.

Search and pages that depend on special characters pass their values as arguments in the url rather than as elements of the url itself. This handles a whole host of errors and when used with UTF-8 encoding and the spring filter system protects against xss attacks.

When a user tries to access the term index page an associated term index function in the graffiti controller pulls the list of unique terms and generates a list. This list is then sorted using the Greek sorting system to account for special characters and greek. For each item in this list the associated data for each term is called and passed to the jsp. The data needed is generated by the [Index Term DAO](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/src/main/java/edu/wlu/graffiti/dao/IndexTermDao.java) and the [Index Term](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/src/main/java/edu/wlu/graffiti/data/rowmapper/IndexTermRowMapper.java) and [Unique Rowmappers](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/src/main/java/edu/wlu/graffiti/data/rowmapper/UniqueRowMapper.java) using the Index Term bean.

The term index list does not display terms that have been blacklisted by an admin and furthermore will eventually be sorted by data on the type of index when such data is added. This will require some sort of interaction with the epidocs.

The data all comes from the graffiti_index table. This table is generated by the [Insert Index Entries](https://github.com/sprenks18/CSCI335_AGP/blob/term_page/Graffiti/src/main/java/edu/wlu/graffiti/data/setup/InsertIndexEntries.java) class which for development purposes be called by the term index page function in the graffiti controller. There is talk of implementing this as a button that an admin could click but I would advise caution because right now it erases all data in the table including whitelist preferences which might not be ideal.