7

is there anything wrong with using html inside a class function? I call it in the DOM so I don't need a string returned.

public function the_contact_table(){ ?> <div> some html here </div> <?php }

Also when I do need the string I use this method? Is there a better way or is this relatively standard?

public function get_single(){ ob_start();?> <div class='staff-member single'> <div class='col left'> <div class='thumbnail'> thumbnail </div> <?php $this->the_contact_table(); ?> </div> <div class='col right'> </div> </div> <?php $content = ob_get_contents(); ob_end_clean(); return $content; }

UPDATE

I should have explained why i am doing this. I'm making a Wordpress plugin and want to control a post types output. So I am using a filter like below

public function filter_single($content){ global $post; if ($post->post_type == 'staff-member') { $sm = new JM_Staff_Member($post); $content = $sm->get_single(); } return $content; }

So as you can see, I must return a string to the wordpress core

Improve this question
3
  • PHP needs to work more, keeping it out of the class renders HTML more quickly.. Commented Jul 29, 2012 at 5:59
  • Look into ZF if you want to learn how to separate your views, models and controllers. Commented Jul 29, 2012 at 6:13
  • Unfortunately this is a Wordpress plugin, I use Zend at work however Commented Jul 29, 2012 at 6:16

3 Answers 3

Reset to default
4

You should be using HEREDOC instead of output buffering if you want to store a long string into a variable. It looks like this:

$content = <<<EOD content here EOD;

EOD can be anything, but note two important things:

  1. It can't have any whitespace in front of it and it must be on it's own line
  2. It shouldn't be a string that could be found within your content

If you are using PHP >= 5.3, then you should use NOWDOC, which does not parse for variable inside the doc (unless you need this). The only different with the syntax of NOWDOC is that the sentinel is enclosed in quotes:

$content = <<<'EOD' content here EOD;

The reason why I'd stray away from output buffering is that it prevents the server from chunking the data sent to the client. This means that requests will seem slower because instead of the content being progressively sent to the client and displayed, it is forced to be sent all at once. Output buffering is a hack for situations when functions carelessly echo data instead of returning it or a tool for certain applications with the specific need for it. I'd also imagine that you'd take a hit on execution time if you used output buffering (because it involves function calls) versus HEREDOCing the string into a variable or including a view.

Now to answer the question about whether it is appropriate, I would say that in an MVC application all HTML and other content should be contained within its own view. Then a controller can call a view to display itself and doesn't have to worry about knowing the code involved in displaying the view. You can still pass information (like titles, authors, arrays of tags, etc.) to views, but the goal here is separating the content from the logic.

That said, Wordpress templates and code looks pretty sloppy to begin with and loosely if not at all implements MVC so if it's too much work to create a view for this, I'd say the sloppiness would fit in with WP's style.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Ok, what is the downside to using output buffering?
@JackMahoney Updated to illustrate the downside of OB.
thanks for the advice. I agree Wordpress can get messy. I need to return it a string so I guess heredoc could be the best solution. Others have mention separating the view from the controller but that would require using output_buffering as I must return a string
I updated my answer, I forgot to show that the function actually returns a string.
@Anther You don't need to comment on my answer to get Jack Mahoney's attention. Since he commented on your answer, if you post a comment on your answer he will see a notification.
|
4

It's not a good practice in regard to the fact that you alienate front-end developers by placing what are actually "Views" inside of PHP class files. This was one of my biggest issues when I first started using PHP in general, is that I wanted to dynamically create content within classes. It's a great idea, but you want to do it in a way that allows many members of your team to work together as smoothly as possible ;].

You should probably have the content inside of a separate file called "staff-member-single.php", which you then call in your function 

public function get_single(){ ob_start(); require_once('views/staff-member-single.php'); $content = ob_get_contents(); ob_end_clean(); return $content; }

You'd refactor that into a reusable method typically though, so it'd look a little bit like..

public function get_single() { $string = $this->render_view_as_string('satff-member-single'); return $string; } public function render_view($view) { require('views/'.$view.'.php'); } public function render_view_as_string($view) { ob_start(); $this->render_view($view); $content = ob_get_contents(); ob_end_clean(); return $content; }
Improve this answer

3 Comments

updated the question to show the application, thanks for your help so far though
I edited my answer to actually show the get_single() function returning a string. The return statement was missing from my code, but it should still fit your example, since when you use require, the view file will still have access to all of the class's variables as if it's still within the class.
Thanks, I am liking this solution. I also appreciate your point about working in a team, as I am a front end developer by day
2

I think it is good practice to use PHP only for logic of application and transmission some data to view layer (template engine). In accordance with this there are some patterns like MVC.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.