azpect/MarkdownToHtmlTranspiler
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

(FIX): Final big commit! Everything looks great!! #36

Merged
azpect merged 1 commits from feature/wiring into main 2025-11-02 22:21:35 -07:00
Conversation 0 Commits 1 Files Changed 9 +224 -137
9 changed files with 224 additions and 137 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
MDtoHTMLUML.pdf
View File

Binary file not shown.

BIN
UMLClassDiagram.pdf Normal file
View File

Binary file not shown.

BIN
UMLClassDiagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 284 KiB

13
lib/commandLineParser.cpp
View File

@ -21,7 +21,6 @@ CLI::CLI(int argc, char **argv) {
ParseArgs(argc, argv);
} catch (const std::invalid_argument &e) {
std::cerr << e.what() << "\n";
PrintHelp();
@ -42,19 +41,20 @@ void CLI::ParseArgs(int argc, char** argv){
output_file = argv[++i];
if (!(IsHtmlFile(output_file))) {
throw std::invalid_argument("Error: Invalid file extension. Expected a '.html' (HTML) file.");
throw std::invalid_argument(
"Error: Invalid file extension. Expected a '.html' (HTML) file.");
}
continue;
}
if (arg == "-o" || arg == "--output") {
throw std::invalid_argument("Error: Missing filename after '-o' or '--output'.");
throw std::invalid_argument(
"Error: Missing filename after '-o' or '--output'.");
}
std::cerr << "Warning: Unrecognized argument '" << arg << "' ignored.\n";
}
}
bool CLI::IsMarkupFile(const std::string &filename) {
@ -89,7 +89,8 @@ bool CLI::IsHtmlFile(const std::string &filename) {
}
// Check if the filename ends with ".html"
return filename.substr(filename.size() - requiredExtension.size()) == requiredExtension;
return filename.substr(filename.size() - requiredExtension.size()) ==
requiredExtension;
}
void CLI::PrintHelp() const {
@ -99,5 +100,3 @@ void CLI::PrintHelp() const {
<< "\t-o, --output <output_file>, optional output filename\n"
<< "\t-w, --watch, enables watchdog\n";
}
// ./parser input_file -w dhuahdakhk -o output

7
lib/commandLineParser.h
View File

@ -31,13 +31,6 @@ public:
*/
CLI(int argc, char **argv);
/**
* @brief Runs Commands
*
* @author Preston Shultz (shultzp1@my.erau.edu)
*/
void RunCommands();
/**
* @brief Prints a list of commands that can be used
*

14
lib/documentConverter.h
View File

@ -1,9 +1,9 @@
#ifndef DOCUMENT_CONVERTER_H
#define DOCUMENT_CONVERTER_H
#include "commandLineParser.h"
#include "parser.h"
#include "watchdog.h"
#include "commandLineParser.h"
#include <functional>
class DocumentConverter {
@ -14,10 +14,18 @@ private:
public:
DocumentConverter(int argc, char **argv)
: cli(argc, argv),
parser(cli.GetInputFile(), cli.GetOutputFile()),
: cli(argc, argv), parser(cli.GetInputFile(), cli.GetOutputFile()),
watchdog(cli.GetInputFile()) {}
void Start() {
if (this->cli.WatchDogEnabled()) {
this->ConvertWatcher();
} else {
this->Convert();
}
}
private:
void Convert() {
this->parser.ParseDocument();
this->parser.WriteOutput();

89
src/main.cpp
View File

@ -1,89 +1,6 @@
#include "../lib/documentConverter.h"
#include "../lib/inlineNode.h"
#include "../lib/parser.h"
#include "../lib/structureNode.h"
#include "../lib/watchdog.h"
#include <memory>
#include <stdexcept>
void test_nodes() {
// For simplicity
using std::make_unique;
using std::unique_ptr;
DocumentNode root;
unique_ptr<TextNode> node = make_unique<TextNode>("text node");
unique_ptr<BoldNode> bold = make_unique<BoldNode>("bold node");
unique_ptr<ItalicNode> italic = make_unique<ItalicNode>("italic node");
unique_ptr<BoldItalicNode> bolditalic =
make_unique<BoldItalicNode>("bold italic node");
unique_ptr<HeadingNode> heading = make_unique<HeadingNode>(2);
heading->AddChild(std::move(node));
heading->AddChild(std::move(bold));
std::unique_ptr<ParagraphNode> para = std::make_unique<ParagraphNode>();
para->AddChild(std::move(italic));
para->AddChild(std::move(bolditalic));
unique_ptr<ListNode> list = make_unique<ListNode>();
root.AddChild(std::move(heading));
root.AddChild(std::move(para));
root.AddChild(std::move(list));
std::cout << root << std::endl;
}
/**
*Preston: Test to see if watchdog works :)
*/
void test_watchdog() {
Watchdog wd("test/input.md");
wd.Start(nullptr);
}
void test_input(int argc, char **argv) {
if (argc <= 1) {
std::cerr << "Usage: <input_file> <?output_file>" << std::endl;
return;
}
try {
if (argc >= 3) {
Parser p(argv[1], argv[2]);
p.Inspect();
} else {
Parser p(argv[1]);
p.Inspect();
}
} catch (const std::runtime_error &e) {
std::cout << "Caught an error: " << e.what() << std::endl;
} catch (...) {
std::cout << "Caught an error: UNKNOWN" << std::endl;
}
std::cout << std::endl;
}
void test_document_converter() {
// Simulate command line:
// program name, input file, watch flag, output file
const char* argv[] = {
"program", // argv[0] - program name
"test/input.md", // argv[1] - input file
"-w", // argv[2] - enable watchdog
"-o", // argv[3] - output flag
"test/output.html" // argv[4] - output filename
};
int argc = 5;
// Construct DocumentConverter with simulated command line
int main(int argc, char **argv) {
DocumentConverter dc(argc, const_cast<char **>(argv));
// Run the watcher (or use dc.Convert() for single conversion)
dc.ConvertWatcher();
}
int main(int argc, char **argv) { test_document_converter(); }
dc.Start();
};

55
test/hello.html Normal file
View File

@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<h1>MarkdownToHtmlTranspiler</h1>
<h3>Project Overview </h3>
<p>The goal is to create a program that reads a file containing text formatted in a simple version of Markdown and converts it into a valid HTML file. The program will need to identify and translate specific syntax (e.g., <code># Heading</code> to <code><h1>Heading</h1></code>, <code>*text*</code> to <code><em>text</em></code>).</p>
<h3>Implementation Requirements (Generated by Gemini)</h3>
<p>Class Hierarchy: Design a class hierarchy to represent the components of your Markdown document. An abstract base class, Element, can define common behavior. Derived classes would then represent specific types of elements, such as Heading, Paragraph, BoldText, and ListItem. This is a perfect example of inheritance and polymorphism.</p>
<p>Object Composition: A Document class can be composed of multiple Element objects, representing the entire file. A Parser class would be composed of helper methods to break down the input string and build the Document object. This shows how you can build a complex system from smaller, self-contained objects.</p>
<p>File I/O and Exceptions: You will need to use ifstream to read the Markdown file and ofstream to write the generated HTML file. Your code should use exceptions to gracefully handle potential errors, such as a file not being found.</p>
<p>Operator Overloading: Overload the << stream insertion operator for your Element and Document classes. This would allow you to easily print the generated HTML to the console or write it to a file, making your code cleaner and more readable.</p>
<p>UML Diagram: The complexity of the class relationships makes a UML diagram an essential part of the project. It will help you plan your design and will be a key component of your submission.</p>
<p>Recursive Descent Parser: This is the primary algorithm you'll use. It's a top-down parsing technique where a set of recursive functions "descend" through the grammar of your simple Markdown language. For example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text() or parse_italic_text(). This method is intuitive and easy to implement for a simple grammar.</p>
<p>Stack: A stack is essential for handling nested elements. For instance, if you allow bold text inside italic text (_This is <em>bold and italic</em> text_), you can push the _ token onto the stack and then push the <em> token. When you encounter the closing </em>, you check if the top of the stack matches. This ensures that all tags are correctly opened and closed. Your presentation can visually demonstrate this process with a stack diagram.</p>
<p>Hash Map or Map: A hash map (std::unordered_map) or a map (std::map) can be used to efficiently store and retrieve the HTML equivalent for each Markdown tag. For example, you could map <code>#</code> to <code><h1></code>or <code>*</code> to <code><em></code>. This provides O(1) average-case lookup time.</p>
<h3>Contribution Policy</h3>
<h6>Branching When working on this project, please use a feature branch (i.e. <code>feature/parser</code>) with a descriptive name. <code>feature/a</code> is not a descriptive name. These branches should be branched off the most recent <code>main</code> branch, we will not make use of a <code>dev</code> or <code>staging</code> branch since the project is small in scale as well as time. <strong>However, if the project becomes larger or out-of-control, a dev/staging branch will be implemented.</strong></h6>
<h6>Commits</h6>
<p>When working, it is best practice to commit code as much as possible, without being over zealous. For example, when a feature or bug is complete, its time to commit. But when you have to make a new function, that does not mean its time. Each team member should use their best judgment.</p>
<p>Commit messages a little bit more important, when working in a team, it is important to provide strong, clear and concise commit messages. In this project, the team will use a simple formula:</p>
<p><strong>(SUBJECT) Title: textual description</strong> </p>
<p>i.e. (FIX) Rendering completed: explain what changed in short.</p>
<h6>Pushing</h6>
<p>When working in a feature branch, pushing and pulling has no restrictions. Feel free to do as much (or as little) as possible. However, you <strong>CANNOT</strong> push directly to <code>main</code>, the VCS will not allow you to do so, but do not make that mistake. When you are ready to merge a feature, you will create a PR and once it has been reviewed and approved it will be automatically merged in.</p>
<h6>Pull Requests (PR)</h6>
<p>Once a feature is complete, you will create a pull request. Before a request can be merged into <code>main</code>, one approval is required (which cannot be the author). This practice is to promote team work and encourage code reviews. Each team member is expected to check in frequently and review as often as they are able to, however, there is no defined time requirement. Personal communication is totally acceptable as a means to request approval, since I am unsure if this platform will notify members.</p>
<h6>Issues</h6>
<p>If a bug, issue, or otherwise concern is noticed the first thing the team member should do is create an issue. An issue should be descriptive and contain everything another team member needs to understand the issue and its context. This way, a new team member can tackle the issue without contextual gaps.</p>
<p>If a member would like to work on the issue themself, the <code>assignee</code> field is where this should be defined. If a member would like help from another member, they should assign the other team member to the issue, and leave a comment in the issue itself describing what help is needed. </p>
<p><strong>Labels</strong> are important for understanding what type of issues/bugs exist in the application. When a bug is created, make sure the proper labels are applied. These labels will be abstract, such as: <code>bug</code>, <code>fix</code> or <code>feature</code> and they will also be specific, such as: <code>parser</code>, <code>i/o</code> or <code>processer</code>. A combination of both styles of labels allows other team members to understand what is going on. If a member feels an issue is missing, they are free to create new ones, but there is a such thing as <strong>too many labels</strong> a few per issue is totally fine. They are not meant to replace the description.</p>
<p><strong>Priority</strong> is the final important factor to consider. In this project, priority will be defined using labels as well. The policy defined above will apply here to priority labels as well. However, these labels are <strong>mutually exclusive</strong>.</p>
<h6>Projects (Sprints)</h6>
<p>The use of the <code>projects</code> tab in the VCS will allow the team to remain organized as create notes and action items that should be completed before one another. These resemble <code>sprints</code> from the <code>AGILE</code> development life cycle. A new "project" should be created when a large piece of functionality needs to be created. Issues can <strong>and should</strong> be attached to the projects they are related too. This will continue to encourage teamwork and organization.</p>
<p>Projects should have defined criteria, such as input and outputs, expectations and a semi-defined timeline. Once a description and is defined, tasks can be added and moved around as needed. The team will use <strong>Kanban</strong> project types, as they are simple and easy to understand for new team members. Reference [here](https://www.markdownguide.org/basic-syntax/)</p>
<p>Headings, h# tags</p>
<h1>Header Level 1 -> <h1> Content </h1> ## Header Level 2 -> <h2> Content </h2> ### Header Level 3 -> <h3> Content </h3> #### Header Level 4 -> <h4> Content </h4> ##### Header Level 5 -> <h5> Content </h5> ###### Header Level 6 -> <h6> Content </h6></h1>
<p>Alternate syntax (n number of =/-)</p>
<p>Header Level 1 -> <h1> Content </h1> ================</p>
<p>Header Level 2 -> <h2> Content </h2> ----------------</p>
<p>Paragraph tags</p>
<p>Hello world -> <p> Hello world </p></p>
<p>This is also a paragraph -> <p> this is also a paragraph regardless </p> regardless </p>
<p>However this is a break, because it ends with two spaces -> <p> However <br> this is a break, because it ends with two spaces </p></p>
<p>Double returns also</p>
<p>yields new paragraphs -> <p> Double returns also</p> <p> yields new paragraphs </p></p>
<p><em>italic</em> -> <em>italic</em> <strong>bold</strong> -> <strong>bold</strong> <strong><em>italic bold</em></strong> -> <strong><em>italic bold</em></strong></p>
<p>hello <strong>world</strong> -> [TextClass: hello, BoldClass: world] </p>
</body>
</html>

115
test/input.md
View File

@ -1,3 +1,118 @@
# MarkdownToHtmlTranspiler
### Project Overview
The goal is to create a program that reads a file containing text formatted in a simple version of
Markdown and converts it into a valid HTML file. The program will need to identify and translate
specific syntax (e.g., `# Heading` to `<h1>Heading</h1>`, `*text*` to `<em>text</em>`).
### Implementation Requirements (Generated by Gemini)
Class Hierarchy: Design a class hierarchy to represent the components of your Markdown document. An
abstract base class, Element, can define common behavior. Derived classes would then represent specific
types of elements, such as Heading, Paragraph, BoldText, and ListItem. This is a perfect example of
inheritance and polymorphism.
Object Composition: A Document class can be composed of multiple Element objects, representing the
entire file. A Parser class would be composed of helper methods to break down the input string and
build the Document object. This shows how you can build a complex system from smaller, self-contained
objects.
File I/O and Exceptions: You will need to use ifstream to read the Markdown file and ofstream to write
the generated HTML file. Your code should use exceptions to gracefully handle potential errors, such
as a file not being found.
Operator Overloading: Overload the << stream insertion operator for your Element and Document classes.
This would allow you to easily print the generated HTML to the console or write it to a file, making
your code cleaner and more readable.
UML Diagram: The complexity of the class relationships makes a UML diagram an essential part of the
project. It will help you plan your design and will be a key component of your submission.
Recursive Descent Parser: This is the primary algorithm you'll use. It's a top-down parsing technique
where a set of recursive functions "descend" through the grammar of your simple Markdown language. For
example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text()
or parse_italic_text(). This method is intuitive and easy to implement for a simple grammar.
Stack: A stack is essential for handling nested elements. For instance, if you allow bold text inside
italic text (_This is *bold and italic* text_), you can push the _ token onto the stack and then push
the * token. When you encounter the closing *, you check if the top of the stack matches. This ensures
that all tags are correctly opened and closed. Your presentation can visually demonstrate this process
with a stack diagram.
Hash Map or Map: A hash map (std::unordered_map) or a map (std::map) can be used to efficiently store
and retrieve the HTML equivalent for each Markdown tag. For example, you could map `#` to `<h1>`or `*`
to `<em>`. This provides O(1) average-case lookup time.
### Contribution Policy
###### Branching
When working on this project, please use a feature branch (i.e. `feature/parser`) with a descriptive name.
`feature/a` is not a descriptive name. These branches should be branched off the most recent `main` branch,
we will not make use of a `dev` or `staging` branch since the project is small in scale as well as time.
**However, if the project becomes larger or out-of-control, a dev/staging branch will be implemented.**
###### Commits
When working, it is best practice to commit code as much as possible, without being over zealous. For
example, when a feature or bug is complete, its time to commit. But when you have to make a new function,
that does not mean its time. Each team member should use their best judgment.
Commit messages a little bit more important, when working in a team, it is important to provide strong,
clear and concise commit messages. In this project, the team will use a simple formula:
**(SUBJECT) Title: textual description**
i.e. (FIX) Rendering completed: explain what changed in short.
###### Pushing
When working in a feature branch, pushing and pulling has no restrictions. Feel free to do as much
(or as little) as possible. However, you **CANNOT** push directly to `main`, the VCS will not allow you
to do so, but do not make that mistake. When you are ready to merge a feature, you will create a PR
and once it has been reviewed and approved it will be automatically merged in.
###### Pull Requests (PR)
Once a feature is complete, you will create a pull request. Before a request can be merged into `main`,
one approval is required (which cannot be the author). This practice is to promote team work and encourage
code reviews. Each team member is expected to check in frequently and review as often as they are able to,
however, there is no defined time requirement. Personal communication is totally acceptable as a means to
request approval, since I am unsure if this platform will notify members.
###### Issues
If a bug, issue, or otherwise concern is noticed the first thing the team member should do is create an
issue. An issue should be descriptive and contain everything another team member needs to understand the
issue and its context. This way, a new team member can tackle the issue without contextual gaps.
If a member would like to work on the issue themself, the `assignee` field is where this should be defined.
If a member would like help from another member, they should assign the other team member to the issue, and
leave a comment in the issue itself describing what help is needed.
**Labels** are important for understanding what type of issues/bugs exist in the application. When a bug is
created, make sure the proper labels are applied. These labels will be abstract, such as: `bug`, `fix` or `feature`
and they will also be specific, such as: `parser`, `i/o` or `processer`. A combination of both styles of labels
allows other team members to understand what is going on. If a member feels an issue is missing, they are free
to create new ones, but there is a such thing as **too many labels** a few per issue is totally fine. They are
not meant to replace the description.
**Priority** is the final important factor to consider. In this project, priority will be defined using labels
as well. The policy defined above will apply here to priority labels as well. However, these labels are
**mutually exclusive**.
###### Projects (Sprints)
The use of the `projects` tab in the VCS will allow the team to remain organized as create notes and action
items that should be completed before one another. These resemble `sprints` from the `AGILE` development life cycle.
A new "project" should be created when a large piece of functionality needs to be created. Issues can **and should**
be attached to the projects they are related too. This will continue to encourage teamwork and organization.
Projects should have defined criteria, such as input and outputs, expectations and a semi-defined timeline.
Once a description and is defined, tasks can be added and moved around as needed. The team will use **Kanban**
project types, as they are simple and easy to understand for new team members.
Reference [here](https://www.markdownguide.org/basic-syntax/)
Headings, h# tags