Is it a bad idea to return the html code from a function or method?

I have this idea:

when someone calls mysite.com/layer1/layer2/something, then I want to start the action called something. That action is simply a file in an actions directory which contains a function. This function takes some context parameters and is supposed to return HTML output. This output, which goes into a variable, will then be brought into an main template, and finally the little framework will throw out the whole html output at once.

开发者_开发技巧Now I don't know if it's good or bad design to return big amounts of html code from a function or method?

This is likely nothing to be concerned with. Just make use of caching if necessary.

There's nothing wrong with returning HTML from a function provided that function lives in the presentation layer and you maintain good seperation of business/controller/presentation logic.

However, in this particular case, I'd recommend having your "action" files just dump their output via echo, and capturing it with output buffering wherever you're doing your original function call. This way, your action files don't have to worry about concatting a bunch of data onto a buffer variable and making sure it gets returned. Also, because these files are (presumably) largely HTML oriented, you'll be able to use the much nicer and more legiable syntax:

<div id="Outer">
  <?= $content ?>
  <p class="Inner">
    <?= $more_content ?>
  </p>
</div>

As opposed to:

$buffer .= '<div id="Outer">' . $content .
           '<p class="Inner">' . $more_content .
           '</p></div>';

At the very least, the first way allows your IDE/editor to perform proper syntax highlighting.

Generally speaking, no its not. You should isolate in a template of some sort and then return the processed template.

For example:

In your action file:

public function iterateList($data, $template = 'default.php')
{
   /* do stuff processing data
   keeping it super simple we'll say $data = array(
     0=> array('title'=>'HEllo World', 'content'=>'lorem ipsum')
     1 => array('title' => 'Look ma im iterating' => 'cool')
   );
   */
   ob_start();
   include($template);
   return ob_get_clean();
}

in your default.php Note everything in local scope of the function including this is available here, ie. $data

<ul>
<?php foreach($data as $item):?>
  <li>
    <h3><?php echo $item['title']; ?></h3>
    <p><?php echo $item['content']; ?></p>
  </li>
<?php endforeach; ?>
</ul>

This way you never have to modify the action to update structure you simple change the args you pass to the function and the template...

The place where its an exception is if you have likk some simple markups functions (ie. view helpers) to do standa snippets of concise html like create a specific form control or a hyperlink or something. But those thing should be in your "action" they should be standalone so you can use them anywhere - if that makes sense.

Read up on MVC and Front Controller and/or Page Controller patterns.

You want to avoid it as much as possible, but there are times when it's ok to do so. Typically if the function is not being called from multiple places and it's not going to be nested in something else or have a lot of dependencies.

Raw HTML output typically leads to messy code and generally makes developers squeamish discussing it.

So the rule of thumb is if you're not going to be doing this as a rule and you're disciplined enough to come back and refactor if you need to use it in more places, go ahead. However, many people do frown on it.

In MVC Frameworks, you will often find this question answered a multitude of ways. Here are two principles that I attempt to live by, with regards to this.

1) Seperate business logic from presentation logic. If the function in question takes input from another source, and simply does some formatting on it, then it is similar to the view helpers used in most MVC frameworks, and thus is seperated from any business logic that processed the input to the function. However, if the function itself is doing logic based upon its input to determine other things about the data, other then simply how to display it, you wind up with a situation where if you have more then one case down the road, this function will begin to grow substantially, and eventually may become impossible to understand, or inefficient.

2) Data processed by the system should be usable in many forms. If your data might be needed for other uses, beyond display, then you may later on find yourself having to refactor, or even duplicate the code, when you realize that you need 'Ted Developer' in 'Developer, Ted', 'Ted Developer' and 'Ted' forms, and your function only returns one of the three.