-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRequest Layout.txt
executable file
·53 lines (45 loc) · 2.26 KB
/
Request Layout.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
A request will be much like an advanced search. User may request in many different fields excluding ID, monologue contents, etc.
The request system will look like:
ID: ID of the request. User cannot request an ID, it will be added automatically.
AddedDate: The date of the request. Not user defined.
Reader: Type of reader. User defined
Gender: Gender of reader. User defined
Tone: Tone of monologue. User defined
Age: Age of reader. User defined.
WrittenInPeriod: Date written. User defined.
Quality: User defined
Character: User defined
Profession: User defined
Setting: User defined
Dialect: User defined
Length: User defined
Source: User defined
Title: User defined
Author: User defined
Playwright: User defined
Translation: User defined
Play: User defined
Setup: User defined
Subjects: User defined
Comments: Additional Comments. User defined
User: Name or ID of user who added the request
Many fields can be left NULL. ID and AddedDate are not left null and are not user defined.
If anything is left out of the information provided, the comments field holds additional request comments.
For the time being, this database will only include reader, gender, tone, and age for simplicity purposes.
Of course, it will also have ID and date added as those are given. User will also be added once the user
system is completed.
Class Outline:
- Variables:
- SQL connection variable, as well as login parameters
-
- Methods:
- createRequestForm: Prints out a request form.
- addRequirement: Add a requirement to the request object.
- addRequest: add the request to the database
- (TEMP) whatAreTheRequirements: show the current requirements of the request. Debug purposes
- fillRequest: fill a request. This will test if the monologue is sufficient to fill the request too.
Either it can somehow find if there are enough similarities, or it will mark the request as potentially
filled and the initial requester will have to confirm that the request is filled.
With requests, some sort of AI system could potentially be implemented to test whether something fills a request,
whether a request being created has already been filled, etc. Perhaps moderators could do this instead, which would
be much easier to program. ***Any thoughts on this?***