I'm trying to keep my code clean by handling POST requests in a presenter instead of the controller and it's quite a hassle. When I do $this->theme->presenter('contact', 'post_view'); to use the post_view method, somehow it starts using the template file only shown in view() and Smarty starts complaining that it can't find template variables. Why can't presenters just handle POST natively like controllers? It would make things much easier to work with.
The Presenter is meant for variable prepping for a view, not to process input, and interact with models. Calling it will generate the view associated with it. Which means they are in your applications output path, not input path.
What it the problem of handling it in the controller? If you do it right, it should not be more than a handful of lines of code, only input validation. The rest of your business logic should go into a model.
I forgot about the model approach. I've been coding raw PHP for over 12 years now and I never took an MVC or HMVC approach before, so I'm learning something new as I go. I'm liking the new method as it keeps things a bit more organized than just loading lots of classes all at once and using them. I keep thinking of \Orm\Model when I hear the word "model" and just assuming it's the proper place for DB interactions, but nothing else.
I'll start using models for this. Thanks!
UPDATE: Wait a second. I just looked at the docs for models and I was right in that it's only meant for DB interaction. The description of a controller most closely resembles what I'm trying to do, but as it's a bit longer than other sections of the controller. I figured that a presenter would be a better choice as I'm processing the contact form section of the one-page site. (View specific)
I think the best way to do this would either be to leave everything in the controller, or make a dedicated presenter for the post view. (AJAX) From what you stated in your post about the fact that presenters are output objects, (makes sense) then I'm going to leave everything in the controller since not much of that code is output based. It's mostly data checking and processing. (Not DB)
Models are for business logic, it is a big and very common misunderstanding that because an ORM interacts with a DB, and it's classes are called "Model", that that's it.
Donate
