Is Include()/Require() with "Side Effects" a Bad Practice

Is include()/require() with side effects a bad practice?

Yes, IMHO it's (very) bad practice unless very explicitly documented.

include or require (and their equivalents in other languages) should normally only introduce new functions into the current scope, and never trigger their invocation.

Why is using side effects bad practice in JavaScript constructors?

In his book Clean Code, Robert Martin says

Side effects are lies. Your function promises to do one thing, but it
also does other hidden things...they are devious and damaging mistruths that often result in strange temporal couplings and order dependencies.

What you described in your comment regarding arrays sounds like a "strange temporal coupling".

Replace php tags in html

I really think you should adopt Smarty template engine as a standard php lib for your projects.

http://www.smarty.net/

Name: {STN_NAM}<br>

From: php variable in html no other way then: <?php echo $var; ?>

Included pages receive variables?

If you define you variable before include page, you don't need any query string. Your variable will be accessed in the included page with just name. for example

$name = "Awais"
include("page.php");

then in page.php

 echo $name; //will print Awais

Is it bad practice to use variable names as function names in conditions?

It is not a bad practice when you limit the usage to certain cases. One of these cases might be dynamically calling functions based on the given GET parameters.

But I would recommend to use call_user_func() instead. It makes clear what you are going to do and the code is much more readable. Remember to always check the existence of the function with is_callable().

call_user_func() will not work with built-in functions though.

PHP: emulate the global behavior on an unknown variable inside a function

You could import all global variables (but Superglobals) into the local scope of the function where you do the include. I don't think it's really a good solution (as it's a hammer) but as you write in your question you don't know which variables are used, so you could localize them like:

$varname = $GLOBALS['varname'];

As an alternative you could inspect the JS file and/or provide the list of variables for a file and add it to the include function as an array. See another answer for some code example.

You could also first pre-include (and throw away) the js file, gather the warnings about undefined variables, import them and then include for real. Some more include/discard/return/variable related chunks of code.

Effectively Theming long stringed dynamic html

Do you know of an efficient and readable way of doing something like
this?

The only readable, maintainable way of doing this is to adhere to the Separation of Concerns. The points here are 1) Decoupling HTML from PHP 2) Implementing a container, like name => HTML content

You should really wrap that into a class, in order to take full advantage of DI and SRP
(see below). So, a class itself would look like as:

class TemplateBlockManager
{
     private $blocks = array(); 

     public function define($name, $file, array $vars = array())
     {
          ob_start();

          if (!empty($vars)) {
              extract($vars);
          }

          require($file);

          $content = ob_get_clean();

          $this->blocks[$name] = $content;
     }

     public function getBlock($name)
     {
         return $this->blocks[$name];
     }

}

File : test.phtml

<p>
   <b>Welcome to <?php echo $foo; ?></b>
</p>

Usage:

<?php

$blockManager = new TemplateBlockManager();
$blockManager->define('header', '/path/to/test.phtml', array('foo' => 'bar'));

// Should output "Welcome to bar"
echo $blockManager->getBlock('header');

This approach has a number of advantages:

• You can prepare several blocks at a bootstrap stage, thus your blocks can be shared
  across your pages. This reduces code duplication

• You can inject an instance of a $blockManager to another classes that generate an output. This is good for unit-testing, as it adheres to the Dependency Injection

• You also adhere to the Single-Responsibility Principle

• You totally decouple HTML from PHP, since your templates contain basic (or none) php logic

• Since your templates are totally decoupled you don't have to worry if they are long or small. You would simply define a path to the one

• And finally, both HTML and PHP code are easy to maintain

---

Related Topics