Jump to content

Interactive web comic aggregator general design?


mysteriousmonkey29

Recommended Posts

Hello, I am currently in the middle of creating a web comic aggregation website. So far, I have written a PHP-based RSS reader that grabs the image source links and publication dates for various web comics from their RSS feeds, and uses this to update a MySQL database. This RSS reader/database updater is configured to run once every several hours and update the database with any new comics it finds. It seems to be working fine, and now I am starting to work on the front end of the website, which needs to grab this information from the ever-growing database, and display it in a user-friendly and interactive format. I wrote the database updater in a fairly procedural way, because it didn't strike me as something that lent itself very much to object-oriented development. However, the front end of the website does strike me as something that I can save myself a lot of time on by coming up with a decent object oriented design first. Unfortunately, I don't have a lot of experience in this, so I thought I would look online for suggestions. So far, I have decided specifically what I would like the front end to do, and have come up with 2 possible approaches to designing it, but am unsure about both.

 

Here's what I would like it to do:

 

(To clarify, when I say the phrase "comic strip," I'm referring to a whole strip like XKCD, Dilbert, the far side, etc., and when I say the phrase "comic," it refers to an individual comic within a comic strip, i.e. the Dilbert comic for 8/30/2016). I would like my webpage, by default, to display a vertically stacked list of the latest comic images from each comic strip in the database. For customization, I want a comic strip control panel, which allows users to decide which comic strips are enabled/disabled, and in what order they are displayed. I would like each comic image to appear between text denoting the name/author of the strip and an individual set of buttons that allows the user to go forward and backward through the archived comics, and also to adjust the size/scaling of the image. Finally, I would like a similar but generalized set of buttons that allows the user to control all the comic strips in the same fashion, but at once.

 

Based on my basic understanding of object oriented programming, and the design approach suggested in this stack overflow answer: http://stackoverflow.com/questions/1100819/how-do-you-design-object-oriented-projects, I came up with one possible design:

 

Two classes: 1) a comic strip class that contains attributes like the comic strip's name, ID number (from my database), enabled/disabled status, and current comic to display (an object of the next class), in addition to functions to get and set each of these variables, 2) a comic class that contains attributes like the image source link, publication date, and scaling percentage, in addition to functions to get and set each of these variables

 

Then the main webpage would contain a comic strip control panel and general comic control panel as described in the desired functionality. In addition, it would contain an array of individual comic control panels, and an array of div tags (or a similar tag), which would be displayed vertically stacked and alternating along with the comic strip names in plain text. Finally, there would be functions for updating comic and comic strip object information from the database, and functions for updating the div tag content for comic display based on the comic object information. All the functions would be called using JavaScript/Ajax from the appropriate buttons.

 

However, I was unsure about this design, so I asked a friend, who suggested that I use a model-view-controller design pattern, which I guess is popular in web development because its potential for separating all the various languages. After reading about this online, I have come up with a possible alternative design:

 

Model: PHP, an array of comic strips, including name and ID number, active/inactive status, and current comic image URL/publishing date

View: PHP generated HTML/CSS, as described before, a comic strip control panel for enabling/disabling and ordering, a vertically stacked list of comic strip names, constituent comic images, and individual control buttons, and a general set of buttons for controlling all enabled comics at once

Controller: PHP/MySQL, a function to update order and active/inactive comic strip status, a function to update a given comic strip's current comic information, and a function to update all comic strips' current comic information at once

 

As I understand it, the controller functions would be called upon user input into the view (clicking the buttons), which would then update the information stored in the model, and then somehow that would trigger a refresh of the view based on the new model information.

 

I am worried I may have missed something in each of these designs (especially the first one), and unsure about the potential merits of one versus another. I was also wondering if it might be possible to combine the two somehow. Does anyone have any suggestions? Help would be much appreciated

Link to comment
Share on other sites

Whether or not the code is procedural or object-oriented doesn't have much to do with design patterns like MVC or how the thing looks. It would be beneficial to use an OOP design regardless of whether or not you also use MVC, and it would probably also be beneficial to use MVC regardless of whether or not you designed everything with OOP. You should always try to de-couple the various languages. The view for example shouldn't contain HTML code mixed in with PHP code, the code for the view should load a template file that contains an HTML template for that view object and then processes the data and the template to add the data to the template and produce the output. You want to make it easy to change something like the HTML structure without changing the PHP code.

Link to comment
Share on other sites

Okay, so you're suggesting I combine my MVC and OOP designs, and then further separate the code by separating the view into PHP that loads a separate HTML file. I think that makes sense. So maybe…

 

A comic strip class and comic class as described in the first design, instantiated within the model as an array of comic strip objects, each containing an array of comic objects. A view, containing PHP code to load and fill in an HTML/CSS template, composed of the 2 general-purpose control panels, and a vertically stacked alternating list of individual control panels and div tags, as described before, with a refresh function to update the div tags based on the model. And finally, a controller with functions called by the buttons in the view, to modify the comic strip and comic arrays.

 

What do you guys think of this design? I have 2 potential concerns with it so far:

1) I'm not sure if it's possible to create an HTML template of variable length (the total number of individual control panels and div tags would need to be dynamic, based on the number of comic strips in my database)

2) I'm not sure whether the controller's functions should destroy the old comic objects and fill in the arrays with new ones every time the page is updated, or whether it should actually go in and modify the attributes of each comic object. Or if there is a third way I'm missing.

 

Thanks again

Link to comment
Share on other sites

It's possible to create variable length templates with the right data structures, you just need to put a loop in your HTML template.

 

When you load a page you load all the information from the database and generate the necessary data structures. Every time a page is loaded a new PHP process is started, so the data from the previous page is not there anymore and has to be loaded again.

Link to comment
Share on other sites

Okay thanks. The loop part makes sense but I'm still a little confused about the second part. Are you saying that it doesn't matter what I do with the comic objects because when I reload the page they will have to be destroyed and re-created anyway?

 

If so, is this still the case if I use AJAX to refresh the content without completely reloading the page? I'm not exactly sure how this works but I have read that it is possible and it seems like it would be a more elegant design than refreshing the page each time.

 

If not, can you clarify what you meant?

Link to comment
Share on other sites

And on a separate note, do you think it is worthwhile to separate individual buttons for the HTML template into a separate class? Specifically I was thinking about making a class for the individual comic strip control panels, so that when I create the list using a loop as you suggested, I can just make each control panel an object of a separate control panel class or something along those lines

Link to comment
Share on other sites

I'm not sure if it's possible to create an HTML template of variable length (the total number of individual control panels and div tags would need to be dynamic, based on the number of comic strips in my database)

That's multiple templates. One template for the "parent" section, including a placeholder for the repeated divs, and another template for the content that gets repeated. You load the smaller template and populate it for each piece of repeated content, and then take that whole section and load it into the placeholder in the parent template. Templates should be able to include other templates, and ideally have minimal logic for things like loop or conditional structures.

 

Are you saying that it doesn't matter what I do with the comic objects because when I reload the page they will have to be destroyed and re-created anyway?

Once the PHP process that runs to generate the page ends, all of the memory is freed and the process is killed. The actual executable process only exists to generate that one page, it doesn't sit there in memory waiting to be run again. PHP automatically destroys any created objects or resources in the process of freeing up the memory that it used to generate the page. You don't have to explicitly destroy anything. The only time you would have an explicit destructor method in a class is if there is some bit of code that needs to run right before the object gets destroyed. The only time I've used a destructor in my own classes is for a config class, to automatically write any config changes back to the database before the object gets destroyed so that any changes will persist the next time a page gets loaded and the config object gets created again.

 

If so, is this still the case if I use AJAX to refresh the content without completely reloading the page?

As far as the web server and PHP are concerned, all requests are the same. PHP can't detect if a request came from ajax or any other method unless you specifically tell it what's going on. (e.g., the request includes a variable like "page.php?ajax=true" that you would check for to see if it is an ajax or "normal" request) Every request to PHP is basically the same, the web server gets a request, runs the specified PHP file, and then PHP produces some form of output or does some other work. Anything else that happens is up to the programmer. If you have a long list of things to show then using ajax pagination can make sense for the interface, and in that case PHP would only return the content for the actual pieces that you're updating instead of a complete HTML document, so it would only use some of the templates versus creating the entire page.

 

Making separate classes for individual buttons may be a little overkill. You can have a generic button class which handles the things that all buttons would need, where you could pass your own function for handling the click event for the button I guess, but since the actual user interaction happens only in the browser and not PHP (PHP just gets another request from the browser, like any other request), then a class for an interface element inside PHP isn't terribly useful. You still need some way to have Javascript react to the click event and send the appropriate request to PHP to handle the click for that button, but you can put all of that in the view template for the button if you want to.

Link to comment
Share on other sites

Okay, I have formulated a few more questions, this time specifically implementing an MVC pattern. First, in my case, would it be the controller that reads data from the database using PHP/MySQL, or with the controller tell the model to read data from the database upon being called into action by buttons on the view? Second, does the controller tell the view to refresh? I have read that a common misconception about the MVC pattern is that the controller passes data directly to the view, so I am pretty sure that the view is supposed to be getting data from the model. However, I am not sure what is supposed to initiate the refresh of the view.

Link to comment
Share on other sites

Hmmm, I've read a lot of posts that contradict that. Upon further googling, the main problem seems to be that no one can agree on how MVC works. Here are a few similar but markedly different flowcharts that I found on Google images:

 

https://upload.wikimedia.org/wikipedia/commons/thumb/a/a0/MVC-Process.svg/2000px-MVC-Process.svg.png

https://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/ModelViewControllerDiagram2.svg/350px-ModelViewControllerDiagram2.svg.png

http://www.moock.org/lectures/mvc/images/mvc-02.jpg

http://help.sap.com/static/saphelp_hanaplatform/en/91/f233476f4d1014b6dd926db0e91070/loio1eb216151b1b41f1979b7b6c969670df_LowRes.png

 

The last 2 seem to make the most sense to me, but in the first of these (third image on the list), I don't get the distinction between the model updating the view and the controller modifying the view. The second part seems redundant. And in the very last one on the list, I don't understand exactly how I would implement whatever they mean by the "data binding" arrow.

 

Very confused

Link to comment
Share on other sites

Also, after thinking about it a little longer, I'm still a little confused about this point:

 

Once the PHP process that runs to generate the page ends, all of the memory is freed and the process is killed. The actual executable process only exists to generate that one page, it doesn't sit there in memory waiting to be run again. PHP automatically destroys any created objects or resources in the process of freeing up the memory that it used to generate the page. You don't have to explicitly destroy anything. The only time you would have an explicit destructor method in a class is if there is some bit of code that needs to run right before the object gets destroyed. The only time I've used a destructor in my own classes is for a config class, to automatically write any config changes back to the database before the object gets destroyed so that any changes will persist the next time a page gets loaded and the config object gets created again.

 

It makes sense that a regular PHP process that just generates HTML gets destroyed after being used. However, most (if not all) explanations of MVC that I have found thus far hold that the model contains permanent data storage. I guessed before that I would write the model in PHP simply because it is the most ubiquitous language in my project, but now I'm not sure if this is the correct choice. Would writing the model in PHP nullify its ability to permanently store data? If so, what should I write it in? If not, then back to my original question about whether it makes sense to populate the model with an array of comic strip objects, each containing an array of comic objects. It seems weird to me to create these arrays using constructors and then go in and modify the attributes of each object from the controller according to user customization. However, it also seems weird to destroy all these objects and then re-create them each time, and if the model is indeed permanent storage for data (or at least permanent until you go to another website or reload), then i don't see a third option and am still confused.

 

Thanks again

Edited by mysteriousmonkey29
Link to comment
Share on other sites

The model's permanent data storage is the database. From the point of view of objects interacting with the model, the model always has the data readily available, but internally it's pulling from the database.

 

 

In my usual implementation the controller takes data from the model and sends it to the view, the model usually never interacts directly with the view. The controller also gives data from the user to the model to be stored. The model takes care of storing information into the database and pulling it out of the database and converting it into a usable format.

Link to comment
Share on other sites

And in the very last one on the list, I don't understand exactly how I would implement whatever they mean by the "data binding" arrow.

That's the template part. Part of the view is the template file. The template gets populated (bound) with the data from the controller to produce the final output.

 

However, most (if not all) explanations of MVC that I have found thus far hold that the model contains permanent data storage.

Permanent data storage takes the form of a database or files. When a new PHP process starts you can read the data that you already have and go from there.

 

If you're creating a new comic strip object then you would typically pass the constructor something like the database ID of the comic strip, or the complete database record. The constructor would get the record from the database if all you passed was the DB ID, then it would populate all of the object properties with the data from the database, and there's your object. That work is done inside the class constructor, you wouldn't manually write that code for every object you create.

Link to comment
Share on other sites

Okay, I have yet another follow-up question (sorry to keep pestering you guys). I started looking into HTML templating, and realized I am not exactly sure what you guys mean by HTML templates, like in your comment here:

 

The view for example shouldn't contain HTML code mixed in with PHP code, the code for the view should load a template file that contains an HTML template for that view object and then processes the data and the template to add the data to the template and produce the output. You want to make it easy to change something like the HTML structure without changing the PHP code.

 

Are you referring to HTML 5 template tags? Or do you mean I should create, for example, one HTML file titled comics_page_template.html, containing my generalized control panels and a placeholder tag for the comics list, then another HTML file titled comic_template.html, containing an individual control panel and a placeholder tag for the comic image, then load the parent template in the PHP view file, fill it with comic templates in a loop, and then use PHP to go in and fill in all the variables (such as comic strip title, and the actual image tags)? Or is there some way of passing arguments to an HTML file using PHP that I am missing?

 

Thanks again

Link to comment
Share on other sites

I call a file a "template" if it's mostly plain HTML with some variables, loops and conditions just for the sake of displaying data. A template file should not do any data processing, it's just there to display the data.

 

In one file you have all your PHP doing all the logic. After all the logic is done, data is assigned to variables that are made available to the HTML template:

 

Here's an example:

 

Logic:

$comics = array(
  array(
    'name' => 'Comic 1',
    'image' => '/images/comic1.png'
  ),
  array(
    'name' => 'Comic 2',
    'image' => '/images/comic2.png'
  )
);

include 'template.php';

template.php:

<h1>List of Comics</h1>
<?php foreach($comics as $comic) { ?>
  <div class="comic">
    <h2><?php echo $comic['name']; ?></h2>
    <img src="<?php echo $comic['image']; ?>" alt="<?php echo $comic['name']; ?>">
  </div>
<?php } ?>
Link to comment
Share on other sites

For the reference of anyone reading this thread in the future, I think I figured out my general design for MVC. The model is a set of PHP/MySQL functions for creating/modifying a list of comic strip objects, each containing their own list of comic objects, as described earlier. The view is a PHP class with an output functions that loads a PHP/HTML template using require '…' as explained by foxy mod. The controller is a JavaScript/Jquery file that listens to button clicks and other user interactions, and then replaces the whole content of the website (which I surrounded with a div id="content" tag for this purpose) with an Ajax load call to the same file but with a corresponding action variable appended to the name of the URL. Then in my index file I have a simple loop that checks if an action is set, executes the corresponding model function, and then loads the view using tthe output function.

 

A simplified version of my JavaScript model file is as follows:

$(document).ready(function()
{
    //$("button").click
    (function()
    {             
        //replace all the content with what the main page returns on this action  using a jquery ajax call
        $("#content").load("index.php?action=desiredMethodFunction");
    });
});

And a simplified version of my index file is as follows:

$model = new Model(); 
            $view = new View($model); 
            if (isset($_GET['action']))
            {
                $model->{$_GET['action']}();
            }
            echo $view->output(); 

Thanks for all the help!

Link to comment
Share on other sites

  • 1 year later...

Hey, sorry for the extremely late reply. I have some free time again, so am resuming work on this project. I was rereading this post, and noticed that I never replied to your last comment.

 

What do you mean, exactly? I guess by "an approach that works without Javascript", you mean that I should write the controller in php, and then call it from the view using get and post, or something along those lines. But I am confused by what you mean when you say to add a layer of javascript on top. If it works without javascript, how would I integrate javascript into it "for convenience"?

Link to comment
Share on other sites

An example is a form submission.  If Javascript is enabled then you can have all kinds of fancy validation before the form gets submitted, and you can even use ajax to submit it and display a nice animation or whatever.  If Javascript isn't running in a particular browser then clicking the Submit button still causes the data to get submitted, validated on the server, etc like normal.

Link to comment
Share on other sites

In general that's usually a goal of accessible website design.  Javascript is nice but ultimately it's just a convenience for the user, all of the heavy lifting should still happen on the server.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...