Crossposted from the main Elgg discussion site:

In doing the rewrite on the folio plugin, I came up with some thoughts and guidelines that helped me with its development I am going to include the below in the ReadMe doe included in the zip as well. I would appreciate any input people may have, as this is still very much a” thinking out loud” process for me.

• MVC Framework
o Folio V.7 is the first iteration that has anything like a model / view/ controller design.
o Each table in the database is an object (model). These are stored in mod/folio /object and are all singular in name (page and not pages).
o All object name, aka folio_page, are prefixed with the mod folder name. This could allow for using php’sautoload feature, removing the need to have explicit include statements.
o The model, aka folio_page , has SQL functions for Select, Update, Insert, and Delete.
I kept these using SQL language, aka Update and not edit, to make them easier to remember. I found this made using things very easy. If I wanted to load a User, change their name, and save, then if is the following easy to understand and write 3 lines.

$user = folio_user::SelectWhereIdent(2);
$user->name =”bob”;
$user->Update();

o Selects have multiple forms, but always a SelectWhereIdent(ident) form for easy loading by the table primary key.
o Controls are in the view/ directory.  Generic ones are in the names of the object (such as comment.php).  More specialized controls are under their main name, e.g. RichEditor.php.
• Html
o Every page hit by a browser is in mod folio html. All Js and css files are in /js and /css . All have a php extension that are turned into js or css thru rewrite rules. This allows a high degree of control over expires headers, using url for full instead of relative paths, and so on.
o The nice thing about this is that we can have standard htaccess rules for all plugins. Anything with /news/title/3 goes to /mod/title/view.php?title=3. Anything with /news/title/3 Bells/edit goes to /mod/title/edit.php?title=3 Bells . Obviously there will still be exceptions, but it would greatly simplify matters.
o Each html page contains as much of the div and layout code that I could factor in there.
• Ajax
o All postbacks go to /ajax folder. As an example, the page edit goes to /mod/folio/ajax/page_update.php . Similar SQL phrases like delete and insert are also used. Part of the Post is a Redirector object. This is used to tell the Ajax page what to do as a result. Standard options include redirecting to another page, echoing a field, and adding a message to display on the next page load.
o The reason I like this setup is that I always know where post backs are being handled, I can have have a high degree of control over the resulting actions, and I can use the save backend for Ajax as well as normal post backs.
• Echo
o The only pages sending non-error output are those in html and ajax . All other are side-effect free to include, all code is safely enclosed in functions.