-
Notifications
You must be signed in to change notification settings - Fork 2
bmatican/geekrpg
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
We will be using a Model - View - Controller programming paradigm, for our applications. As such, we will have Models that represent our data and the means to manipulate it. We will have Views as the ways in which we dispaly the data. Finally, we will have Controllers which will guide the received requests, from the site-level, after being dispatched to the respective application, directly into doing the necessary actions to the data and display. Our overall file/folder structure is as follows: . ├── applications/ │ ├── core/ │ ├── skeleton/ │ └── sample/ │ ├── controllers/ │ ├── helpers/ │ │ ├── functions.php │ │ └── class.handlers.php │ ├── models/ │ └── views/ │ ├── controller1/ │ ├── ... │ └── controllerN/ ├── config/ │ └── config.php ├── images/ │ ├── image1 │ ├── ... │ └── imageN ├── index.php ├── library/ │ │ ├── class.class1.php │ │ ├── ... │ │ └── class.classN.php │ ├── css │ │ ├── cssfile1.css │ │ ├── ... │ │ └── cssfileN.css │ ├── js │ │ ├── jsfile1.js │ │ ├── ... │ │ └── jsfileN.js ├── README ├── scripts/ │ ├── scripttype1/ │ ├── ... │ └── scripttypeN/ │ ├── script1 │ ├── ... │ └── scriptN ├── templates/ │ ├── template1/ │ ├── ... │ ├── templateN/ │ └── Default │ ├── css/ │ ├── js/ │ └── default.php ├── TODO └── views/ ├── view1.php ├── ... └── viewN.php inside the application folder there will be 2 folders by default in it: "core", "skeleton". The "core" is where our main, application level core functionality will reside. The "skeleton" is just a mock folder for easily reproducing and developing on the framework. Inside each application folder, there will be 4 folders: controllers/ will hold the controllers, responsible for taking user input and directing it between the models and the views models/ will hold the database models representing the abstraction layer as long with all interactions with the data/storage level views/ will hold a folder for each relevant controller, each with its own pages to be rendered at a controller's request helpers/ will hold files that will be included for use throughout the application; of special interest is the "class.handlers.php" which can contain handlers for hooks set up in various controllers throughout the framework, as well as dynamically created methods for controllers Inside the config folder, there will be general configuration settings for the entire framework, and/or potentially for individual applications as well, such as which ones are enabled and so on. They are currently stored in "config.php". Inside the images folder there will be globally available images. Inside the library folder there will be globally available functionality. Inside the scripts folder there will be scripts for various languages to aid in the running and execution of various tasks, such as DB import/export and so on. Inside the templates folder there will be a number of website "skins" basically each with it's customizable look and feel. There will, also, be a "Default" implementation included. Inside the views folder there will be globally accessible renderable pieces. As extra, there are also a README file (this one), a TODO file (which is generally outdated) and the "index.php" file, which is the main entry point into the application. This file will basically load up all the active applications, include their relevant files, prepare their internals for use, such as resolving hooks/handlers and ultimately, decyphering the user request for delivering it to the dispatcher. This final piece is where the request is transformed into an internal call to the framework. [WORKFLOW] Normally, a request is done to /index.php?q=queryparam. This is then, at index.php level split up into components. The "queryparam" is assumed to be in the form of controller/method/arg1/.../argn. These are then forwarded to the dispatcher, which will attempt to find the respective controller and call the method invoked, with the respective parameters. Then, at controller leve, if that method does not exist, it will look to see if by any chance, some Handler class did not register any methods dynamically for execution with the respective name. In case it finds something, it will try to call that function with the respective parameters it was passed. Alternativelly it will end up calling a protected method _undefinedMethod(), which can be overridden in subclasses, but by default just renders the 404 page of that respective controller. There is only one exception to this rule, in case we have only one argument to query, in which case it is considered to be an explicit request for a page, to be handled by the page controller, so /index.php?q=signup will be actually a request to /index.php?q=page/signup . This works great for GET requests, but for POSTs, we have designed a Form abstraction that will, via hidden inputs, direct the fields in a form, to the dispatcher, in such a way that internally, the required function will end up being called, with the respective parameters. One just has to specify the desired destination for the form, in the sense of which end point it should hit in the website, and the order in which the internal fields should go as parameters to that respective function. We have yet to implement Forms which use GET as method...
About
the website for our university cs club
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published