So, I am returning to my original plan and not continuing to implement the functionality to extract and parse text content from user-given urls. The reasons for this being:
1) Having my server held responsible for opening and loading the contents of every user submitted url is probably not a great idea
2) If I want to make Scaffold into a web app, I need to divert from rewriting and adding to back-end functionality. Instead, I should ensure that the functionality I have already implemented is being constructed in a way that will work well with the web app architecture. Particularly when considering additional resources that might be necessary to improve Scaffold's overall identification error rate.
As it stands, my plan is to use Flask to connect my back-end to a simple html/(possibly CSS) front-end. Ultimately, my goal is to build a web app that demonstrates the Scaffold parsing/identifying functionality in a clean and reliable way.
I am back and forth about when the appropriate time is to introduce a database component to my stack is. Keeping track of all of the documents that Scaffold is being fed as well as their results would be most appropriately accomplished by a database.
On the other hand, Scaffold does not need a database in order to perform its parsing and other token-tagging tasks for this iteration of the logic. For testing, I could stick with my plan to export Scaffold inputs and results to text documents and writing a Python program to parse those results for feedback figures.
What I really need to do is lay out what specific data I would like Scaffold to give me each time it runs, what metrics I want to pull out of that data, and what the best way to accomplish that is. Keeping in mind that I will almost certainly want to keep a record of the details of every instance that someone runs Scaffold. Okay. Yes. I almost certainly need a database, now that I think about it.
All in all, here's what I'm thinking for my current game plan -
->Build simple HTML front-end consisting of non-negotiable components
->Text box to collect input document
->'Go' Button to indicate that the contents of the input box should be processed by the back-end and made into a Scaffold
->area to display enumerated lines of original article
->tables for People/Locations/'Other Subjects' containing counts and line citations to specific occurrences
->some kind of minimally readable display of quotes/event dates and times/data points and their line numbers
->use Flask to render HTML templates and call back-end functionality (forgive me for mis-wordings, I literally started using Flask yesterday)
->Plan on a lot of debugging, rejoice if it is less than a lot
->Once the front-end can take in input, push it through the back-end meat grinder, and display the results, determine design of database I want to store inputs and results in
->set up MySQL database and add calls to store desired program data for each instance that Scaffold is run
->Plan on a lot of debugging, rejoice if it is less than a lot
->While on localhost, verify that there are no runtime errors for a basic set of test documents and edge cases
->verify that the database appears to be storing data as expected
-> Determine where I want to host a publicly accessible version of Scaffold and throw it up on there
->resume testing plans described in my first Scaffold blog post, modified as appropriate to incorporate the new set up
Hopefully, that turns out to be a reasonable course of action. If not, I'll rework it as necessary. For now, I just want to stop blogging about it and start building it!
Although I should probably make all of those bullet points into a todoist list first.
No comments:
Post a Comment