How to avoid switch in index

[xmohamadx]

I use this function from Jason Knight to get REQUEST_URI:

Code: [Select]

<?php

(function() {
  $path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
  if (strpos($path, '..')) die('Hacking Attempt Detected, Aborting');
  $path = str_replace(['\\', '%5C'], '/', substr(
    $path,
    strlen(pathinfo($_SERVER['SCRIPT_NAME'], PATHINFO_DIRNAME)) 
  ));

  if (empty($path)) 
    define('REQUEST', [ 'index' ]); 
else {
    $path = explode('/', $path);
    foreach ($path as &$p) $p = urldecode($p);
    define('REQUEST', $path);
  }
})();

And inside my index.php, I need to output templates based on REQUEST[0], so this is what I do right now:

Code: [Select]

<?php

(function() {

  // startup includes like common.template.php and common.lib.php which holds the above function

  $pdo = new Database(
    ':host=localhost;dbname=mohamad;charset=utf8',
    'username',
    'password');

  switch (REQUEST[0]) {
    case 'home':

      template_header('title');
      template_foo();
      break;

    case 'blog':

      $blog = new Blog($pdo);
      $stmt = $blog -> read();
      $blogData = $stmt->fetchAll();

      template_header('title');
      template_blogSummary($blogData);
      break;

      // and so on
  }

  template_footer();

})();

So it seems a bad practice to do it with switch.
One way is to use actions, writing codes of each case inside a single action.php, and only include it in the index. The problem is that I cannot use safeInclude, because I need to send data from the database as an argument.
Another way is to use the switch with functions that hold codes of each case, a little clarity, but still, need to use the switch.

[benanamen]

The switch has to go. It is not scalable. There are a couple ways to go.

One option is to dynamically map the request to a file. This option is okay for a small site but has the drawback being that your folder structure is locked and cant be changed without changing URL's.

The more scalable option is to use a Router. Either one you write yourself or one of the many that are available. This will allow you to change your folder structure at will without affecting your URL's and SEO. This leans more towards a framework type of architecture and is best suited for OOP. To be clear, I am not say A framework, just that type of architecture composed of components.

[Jason Knight]

I agree that switch isn't the way. My preferred approach -- and why I don't allow ".." in my uri's, is to use request[0] as the path to my includes.

Generally:

/actions/REQUEST_NAME_HERE.start.php
/actions/REQUEST_NAME_HERE.content.php

I run the "start" one and then use whatever it sets up for values to plug into the template header. Then I load the appropriate .content.php, then send template_footer.

As to "routers", what @benanamen means by "more scaleable" to me just means "more code for no good reason other than making it more complex"... since structure being locked is good, and "changing URL's" is meaningless tripe since everything should be linked relatively.

Actual underlying folder structure having dick all to do with URI's if you're trapping things properly for the "one index" approach. Well, other than for actual static files... which shouldn't conflict if your structure is worth a damn from the start!

Hence why when people start talking about "routers" I know they're just throwing endless pointless garbage code at things for no reason, since objects like Request and some simple code to process the values returned by it should be all the "routing" you would ever need. But no, some people feel the need to slop endless pointless convoluted classes at even the simplest of things.

Process the user request, gather the data, output it to the user in the template. Anything else is rubbish.

[xmohamadx]

Thank you Jason Knight

Can you give a sample code of start.php and content.php?
I would like to know how you did that for cutcodedown.com blog

[benanamen]

I was expecting your comments Jason. The "problem" with not using a router is you are dumping ALL your files into a single directory. There is no flexibility to organize those files into a meaningful directory structure. A small site would be OK. A large site would be a cluster muck of all sorts of files dumped into a single directory. Your way also hardcodes URLs to file names. By routing, you have the option to name your files anything you want with no regard to the URL. Routing allows you to completely decouple the URL from physical files.

 Being able to move files around without affecting the URL is just a small side benefit.

Organizing related files into an organized directory structure is far from "making it more complex".

[Jason Knight]

The "problem" with not using a router is you are dumping ALL your files into a single directory.

No, I'm dumping all my category files into a single directory. If I have blog entries they're handled by blog.*.php. If they're static files they're handled by static.*.php and/or as a fallback on name miss. Generally speaking even the largest forum software wouldn't / shouldn't need more than around 40 file-pairs in there, and if that's too "unweildy" then there's something else wrong with the architecture...

... like piss poor planning.

There is no flexibility to organize those files into a meaningful directory structure.

Unless of course you START with a meaningful directory structure and/or storage. Such as a matching directory for the file-pairs for subfunctions. Such as keeping like data in like directories. Such as leveraging a database or specific subdirectories for specific content.

The folks using this router crap seem to just be using it to avoid making directory structures that make sense and provide for extensibility FROM THE START!

Which is why people end up with multi-megabyte monstrosity shit-storms of inefficient websites doing the job of 1/10th the flipping code!

Your way also hardcodes URLs to file names.

1) You say that like it's a bad thing, how dare I make the filename the same as the functionality so ANYONE can figure out what file actually does what command. Because of course, naming everything differently is SO useful and clear.

2) It's only PART of the URL that's mapped. REQUEST[1] would be handled by the "action" containing the separate subpages. That's how "one index" with rewriterules is supposed to work after all.

By routing, you have the option to name your files anything you want with no regard to the URL. Routing allows you to completely decouple the URL from physical files.

You say that like it's a good thing, when all you're doing in that case is making it harder to maintain, harder to follow, and introducing unnecessary bloated code on top of it. Seriously if you're naming files with "no regard" to the actual command being called from client side? PLEASE, back the **** away from the keyboard. That's seriously the dumbest thing I've heard in the last... 72 minutes. Working on a proposal for a client where I'm starting to think that dealing with the stupid of their "database manager" is above my pay grade. And I'm telling their boss that as soon as they call me back.

Organizing related files into an organized directory structure is far from "making it more complex".

Exactly what I'm advocating and what you seem to be arguing against.

/ -- index.php, config files

/actions -- handlers

/actions/actionName -- data for the handlers if not DB driven

/template/templateName -- CSS

What benefit is there to having the names not match, other than making everything harder to digest/follow/understand, and introducing more code and more processing to the whole mess by forcing some sort of lookups between the actual name and the user request?1? Much less the overhead of loading the entire lookup just to know what file to call?

Utter nonsense and why this whole "routing" crap is bloated trash. The type of waste and ignorance I expect originated from the "career educator / career student" crowd. Much akin to the "big iron" IBM dinosaurs who billed by the K-LoC 40 years ago, or DEC's foray into the PC world in the '90's, where us Microcomputer guys pointed at them and laughed. Some mistakes just seem to repeat themselves.

[benanamen]

Do you happen to have a CRUD application you wrote so I can see everything in action you are talking about?

[Jason Knight]

Do you happen to have a CRUD application you wrote so I can see everything in action you are talking about?

Don't need a full application to explain it. Simple directories and "traffic cop" mentality.

Let's use a blog as an example:

/actions/blog_start.php -- contains a "content_start()" method that sets up any variables we need for template_header, loads any extra template includes needed for output. Gathers all data and/or data-handlers (such as PDO statements) storing them on a returned data object.

/actions/blog_content -- send the data through the appropriate template_functionName (s)for output.

Request[1] typically holding the target element name/identifier, with sub-functions being controlled by POST so as to make it harder to MITM or XSS exploit it.

For example:

/actions/blog/blog_create.php
/actions/blog/blog_read.php
/actions/blog/blog_update.php
/actions/blog/blog_delete.php

You tree everything down with a logical order from the start. You might even have POST used to add ajax equivalent traps internal to those functions. (I like to actually treate ajax as a template that outputs JSON or ASCII control codes instead of HTML. Yes, I said ASCII control codes!)

And for common things that might pollute the action directory, you just give them a subfolder too.

/actions/errors/404.start.php for example.

That way your main php can just:

$settings = Settings($db, [ ... $iniFiles ]);
$data = action_startup($settings, $db);
template_header($settings, $data);
action_content($settings, $data);
template_footer($settings, $data);

Where again, template_header creates EVERYTHING above <main> and template_footer creates everything after </main> including things like sidebars, modals, etc. $data and $settings holding all the relevant information needed to determine what needs to be shown and where. Preferably the above would be done in a IIFE or static object to create scope isolation. Passing $DB only where needed also reduces the window in which an elevation hack can do malicious damage. More so if you restrict write access so PHP cannot write the files it can execute. Shame there's no way to restrict reads to just "include/require".

If you bother thinking through your directory structure and what commands will need to be called FIRST, you don't need "routing" through endless pointless garbage object overhead, pissing and moaning about side effects to make ten times the code complexity, and make the mere notion of "changing URI's" utter and total garbage.

In a way what I'm doing is routing, but I'm doing it on the filesystem instead of wasting time on dozens of pointless objects and hundreds of possible lookups that you just don't need!

Leverage the existing OS capabilities and how the language seems to have been set up to work, instead of shoe-horning in programming "paradigms" and models that really don't fit the language.

[benanamen]

Don't need a full application to explain it.

I wasn't asking for the sake of explanation. I am willing to entertain your concept without just throwing it out the door. I wanted an actual CRUD app you wrote implementing what you say as a working base for our discussion and for testing scenarios. I "used to" code in a manner you describe so the architecture is not foreign to me. After all these years I am sure you have "something" in your archives as to not have to write anything new.

[Jason Knight]

I wanted an actual CRUD app you wrote implementing what you say as a working base for our discussion and for testing scenarios.

Hah, foist by my own petard! I'm the one usually saying "show the work"

And in this case, I can't. Not because I don't have any, but due to issues with the law. I can't show you the medical sites because even just exposing the database structure violates HIPAA. I can't show you the federal agency stuff or I'd endanger my DOE certification and my clearance, I can't show you the public utility stuff because of the language of the contracts (you want to talk an uptight and unreasonably litigious lot)... and I'd rather not share the third industry I've done stuff for as many would find it offensive.

And all my personal stuff is semi-static "poor mans" right now. I don't use it on my own stuff because I don't need it.

NOT that what people would call "CRUD" -- "Create, Read, Update, Delete" for those who don't know the term -- is anything special in and of itself, and whilst part of routing it's part of EVERY back end, so I fail to grasp the distinction.

CRUD seems to just mean "what a back end would/should be doing with user data anyways"... though some people restrict it to mean a specific bloated endless pointless object and overhead inducing train wreck. It's part of why to my mind the difference between CRUD and REST is absolutely bupkis apart from syntax and the gullibility of the masses for hot and trendy buzzwords.

It oft feels like just another of the many sick euphemisms and programmer double-talks that raises the hackles on my hackles. That's the problem with a lot of the lingo being used right now in programming. "Closure" when they mean enclosure, "Functional programming" when they mean the wasteful overhead of endless pointless separate functions for nothing, "side effects" on things that are not side effects if you're doing them INTENTIONALLY, "Agile" when they mean we have dozens of programmers and no plan, everyone just go do your own thing, "Big data" when they mean "I'm too stupid to work with this much information", etc, etc, etc...

Right back at you though, what would you hold up as an example of a good existing "routing" approach? I've never seen one that wasn't a over-sized, over-thought, over-engineered disaster where people try to take one single approach to data handling, and blanket apply it to everything where it just doesn't fit.

... and normally I like things that are over-engineered, but as Scotty would say the more they overwork the plumbing, the easier it is to stop up the drain.

If you want to start a separate thread (we should stop threadjacking here) where you present/explain what you think good "routing" is I'd like that; if for no other reason than to see if you can convince me that I'm wrong. I often like to che-checkity-check myself ... Big code in your site is bad for its health.

That's the issue, most of what I see -- and have ripped apart -- for clients that uses "routing" is stuff I wouldn't even HAVE a "library of code" to show... as every data set is usually re-arranged to be simpler with far simpler handling methodologies on a case-by-case basis. I generally don't have a "off the shelf" -- even off my own shelf -- answer to problems of said nature because -- in my experience at least -- you sooner or later end up trying to shove a cow's size 20 hoof into a ladies size 4 pump.

It's the core concept behind the "flaw of averages"and the "complexity mismatch" trap. People end up jumping through flaming hoops of fire to make specific "programming paradigms" work in their "ecosystem of tools" that they waste time and dozens of k of code on things that should just be ten to twenty lines. Particularly if an update of one item involves updating other values in other places.

Hah, funny simile as it makes me ponder my choices and mindset. Is my distaste for off the shelf answers to problems stemming from how in the real world I've NEVER once been able to buy anything fancier than t-shirts and sweat-pants off-the-rack without massive alterations? One size fits all usually fits nobody.

A bespoke suit always fits... and remember: oxfords, not brogues!

[xmohamadx]

Thank you for the example, Jason Knight

I tried to understand and learn, but actually I'm a little confused. A sample code will be very helpful here.

As far as I figured it out, first and before sensitive data, I should include these two files with other includes inside index.php IIFE:
/actions/REQUEST_NAME_HERE.start.php
/actions/REQUEST_NAME_HERE.content.php

and then:

$settings = Settings($db, [ ... $iniFiles ]);
$data = action_startup($settings, $db);
template_header($settings, $data);
action_content($settings, $data);
template_footer($settings, $data);

so my "index.php" goes like this:

Code: [Select]

<?php

(function() {

  // contains objects, actions and etc
  include('libs/startup.php');

  $pdo = new Database(
    'mysql:host=localhost;dbname=mohamad;charset=utf8',
    'username',
    'password');

  $settings = Settings($db, [ ... $iniFiles ]);
  $data = action_startup($settings, $db);
  template_header($settings, $data);
  action_content($settings, $data);
  template_footer($settings, $data);
})();

This is "blog.start.php":

Code: [Select]

<?php

function action_startup($db, $settings) {
  $data = [];
  // setting up variables
  $data['page_title'] = 'Blog';

  if (isset(REQUEST[1])  && empty(REQUEST[1])) $data['current_page'] = 0;
  if (isset(REQUEST[1]) && is_numeric(REQUEST[1])) $data['current_page'] = REQUEST[1];

  // functions to read from the database:
  safeInclude('actions/blog/blog_read.php');

  // blog posts to show in summary page
  $data['blog_posts'] = read($settings['posts_per_page'], $data['current_page']*$settings['posts_per_page'] , $settings['local']);

  // needs for pagination
  $data['total_pages'] = ceil(total()/$settings['posts_per_page']);

  // db datas for extra subSection and anything else

  return $data;
} // action_startup


as you said to put CRUD in subdirectories, this is "/actions/blog/blog_read.php":

Code: [Select]

<?php

function read($limit, $offset, $local) {
  // prepare query statement
  $stmt = $this->pdo->prepare('blog.read');

  $stmt->bindValue(':limit', $limit, PDO::PARAM_INT);
  $stmt->bindValue(':offset', $offset, PDO::PARAM_INT);
  $stmt->bindValue(':local', $local, PDO::PARAM_STR);

  // execute query
  $stmt->execute();

  return $stmt;
} // read

function readSingle($url, $local) {
  // prepare query statement
  $stmt = $this->pdo->prepare('blog.read_single');

  $stmt->bindValue(':local', $local, PDO::PARAM_STR);
  $stmt->bindValue(':url', $url, PDO::PARAM_STR);

  // execute query
  $stmt->execute();

  return $stmt;
} // readSingle

function total() {
  // prepare query statement
  $stmt = $this->pdo->prepare('blog.count');

  // execute query
  $stmt->execute();

  // fetch query
  $result = $stmt->fetch();

  return $result['total'];
} // total


and for the "blog.content.php":

Code: [Select]

<?php

function action_content($settings, $data) {
  template_blog_summary($data['blog_posts']);
  template_pagination($data['current_page'], $data[total_pages]);
  template_extra($data[...]);
} // action_content

So am I going through each step correctly?

and one more question, you said:

/actions/blog/blog_create.php
/actions/blog/blog_read.php
/actions/blog/blog_update.php
/actions/blog/blog_delete.php

If I separate the functions for CUD and put them all in the admin directory, wouldn't it be safer and one more safety ring?
like this:
admin/actions/blog/blog_create.php


Thank you so much for your helps

[benanamen]

Ok, so CRUD really isn't what we need. That is just what I am always working with. We really just need  generic  static pages example to start from. So let's start with a new thread with complete code of a couple static pages and I will go from there. I am sure it will be quite easy for me to show the problems when you get scale with it.

[Jason Knight]

So am I going through each step correctly?

You're definitely on the right track. You have a few rookie "mistakes" that are more efficiency nitpicks than "OMFG it's gonna blow up" -- and that's fine.

For example, don't waste time checking "isset' twice on the same variable, and you actually didn't catch all the possible conditions.

Code: [Select]

$data['current_page'] = (
empty(REQUEST[1]) || !is_numeric(REQUEST[1])
) ? 0 : REQUEST[1];
Empty actually also does !exists, so it kills two birds with one stone. From there a ternary operator is your friend.

If I separate the functions for CUD and put them all in the admin directory, wouldn't it be safer and one more safety ring?

Honestly no. Where the files are on the drive really shouldn't make a difference.

That might sound odd, but i you get users implemented so that you can tell if someone is admin or not, where the include file is really does nothing. In that case it's more on how you verify the user permissions than it where/how you include it.

Or at least, if you break scope with the derpy "safeInclude" method.

One of the big issues I have with PHP is how badly it bleeds scope. Wherever you do a include you inherit the local scope. For example:

test.php

Code: [Select]

<?php
(function(){
  $test = 'hello world';
  include('testInclude.php');
})();

testinclude.php

Code: [Select]

<?php
echo $test;

Will output "test". If you come from languages with actual good practices of local handling with modules/units, they'd NEVER allow that.

If we make this mind-numbingly dumbass function:

Code: [Select]

function safeInclude($file) { include($file); }

(function(){
  $test = 'hello world';
  safeInclude('testInclude.php');
})();

it will throw a variable undefined error, because it inherits the local scope of safeInclude, and not our anonymous function.

One of the many things I think should be built into PHP.

IF you're breaking the scope, then only passing what data or settings are needed, and using define or getter/setters for things like user permissions, the file's location in the tree really doesn't matter.

Particularly for code appendages or direct calls, which wouldn't have $db to pass to anything.

It also helps that the rewriteRule for "one index to rule them all" (or its ngnix equivalent) prevents any direct calls to .php files, or any other files not on the whitelist. Part of why I use a whitelist instead of blacklist or blanket redirect.

[

[xmohamadx]

/actions/blog/blog_create.php
/actions/blog/blog_read.php
/actions/blog/blog_update.php
/actions/blog/blog_delete.php

Isn't better to put the functions for CRUD in "database" directory beside queries? (Referring to Squire 3 / Paladin X.3 db directory recently added)
like this:
/database/mysql/crud/[module]/[module].read.php

so for blog:
/database/mysql/crud/blog/blog.create.php
/database/mysql/crud/blog/blog.read.php
/database/mysql/crud/blog/blog.update.php
/database/mysql/crud/blog/blog.delete.php

and for example, "blog.read.php" could be something like this:

Code: [Select]

<?php

final class BlogRead {
public function multiple($db, $limit, $offset, $lang) {
$stmt = $db->prepare('readMultiple', 'blog', false);

$stmt->bindValue(':limit', $limit, PDO::PARAM_INT);
$stmt->bindValue(':offset', $offset, PDO::PARAM_INT);
$stmt->bindValue(':lang', $lang, PDO::PARAM_STR);

$stmt->execute();

return $stmt;
} // multiple

pubic function single($db, $url, $lang) {
$stmt = $db->prepare('readSingle', 'blog', false);

$stmt->bindValue(':lang', $lang, PDO::PARAM_STR);
$stmt->bindValue(':url', $url, PDO::PARAM_STR);

$stmt->execute();

return $stmt;
} // single
}

putting all CRUD functions in one place seems to keep action clean and sometimes the same function is needed in another action, if blog_read is needed in more than one action, updating functions is easier in one place.

[Jason Knight]

Thing is you shouldn't ever need all of them loaded at the same time, it could even be insecure to do so. Don't load dead code in a source-distributed scripting language, you're just wasting memory and processing time!

That's where a LOT of "object driven" stuff becomes slow trash, loading a ton of code you're not even going to call every time. That's why my setup has a LOT of divisions and loading and an organized path tree. I try to avoid loading anything I'm not going to run.

You would generally NOT do a create and delete at the same time. or a create and update at the same time. You're unlikely to pull up a directory (multiple) and an entry (single) during the same page-load.  You slop them all into one file or one object, you're loading dead code. More to load, more to cache, more to parse, more to run... we have a word for that in programming.