Form and View question

[TomTees]

What is the relationship between an HTML form and the "View" in the MVC model?

 

Is the View a class linked to the Form?

 

Would someone please help me better understand this

 

 

TomTees

 

[trq]

A 'view' is the part of the MVC that produces output. 'View Scripts' are basically like templates that can also contain 'View Helpers'. These are typically gathered and processed via a 'View' object, which in turn passes output to the 'Response' object.

 

A html 'form' per say could (and often is) implemented as a 'View Helper'.

 

You may also have a 'Form' object which is specifically designed to validate user inputted data, before passing that data to a Controller for processing by a Model. This 'Form' object would not be considered a part of the 'View'

[TomTees]

A 'view' is the part of the MVC that produces output. 'View Scripts' are basically like templates that can also contain 'View Helpers'. These are typically gathered and processed via a 'View' object, which in turn passes output to the 'Response' object.

 

Hey, don't make this even more complicated?! 

 

Can you give me a simple example of a 'View Script'?

 

Can you give me an example 'View Helpers'?

 

And what is this 'Response' thing?! 

 

 

A html 'form' per say could (and often is) implemented as a 'View Helper'.

 

Let's say I had a Log-In form with only an "Email" and a "Password" input field.

 

How would what you are describing about be done?

 

 

You may also have a 'Form' object which is specifically designed to validate user inputted data, before passing that data to a Controller for processing by a Model. This 'Form' object would not be considered a part of the 'View'

 

Why not?

 

If a Log-In Form could be part of the "View", then why not a Log-In object?

 

 

 

TomTees

 

[trq]

Most of these examples will be highly out of context, because your implementation would depend entirely on how your framework is designed.

 

Can you give me a simple example of a 'View Script'?

 

They are basically html files with minimal php within them. Template like.

 

<div id="blogs">
<?php foreach ($this->blogs as $blog): ?>
  <div class="blog">
    <div class="header"><?php echo $blog->title ?></div>
    <div class="content><?php echo $blog->content ?></div>
    <div class="footer"></div>
  </div>
<?php endforeach; ?>
</div>

 

Can you give me an example 'View Helpers'?

 

Helpers are just that, classes built to aid within a view script. So, something like....

 

<div class="footer"><?php echo $this->helpers->format->author($blog->author) ?></div>

 

And what is this 'Response' thing?!

 

The Response object is generally responsible for storing output (and headers) reading to send back to the client (respond).

 

Let's say I had a Log-In form with only an "Email" and a "Password" input field.

 

How would what you are describing about be done?

 

Something like....

 

<form action="action.php" method="post">
  <label>Your Email:
    <?php echo $this->helpers->form->text('umail', array('size' => 32)) ?>
  </label>
  <label>Your Password:
    <?php echo $this->helpers->form->pass('upass', array('size' => 32)) ?>
  </label>
  <?php echo $this->helpers->form->submit('Login') ?>
</form>

 

Of course you would likely also have methods available to produce the opening and closing <form> tags as well.

 

Why not?

 

If a Log-In Form could be part of the "View", then why not a Log-In object?

 

Because logging in is a 'process', not something to look at (view).

 

These examples probably won't help much within this context. I know you said you weren't keen on using an existing framework (not sure why as its probably the best way to learn good design & OOP) but you should at least be looking at the documentation of some of these frameworks. (Zend's is awesome, though maybe a little steep - http://framework.zend.com/manual/en/manual.html). Look at there documentation and implement your own design if you like, its a good reference for this sort of thing.

[trq]

I should probably explain where $this comes from within the view script as well considering they themselves are not classes (and I'll bet that's your next question).

 

Within your controller script you pass data into the 'View' object. This in turn would have a render() method which would be responsible for pulling in the view script (via include). This means that $this within your view scripts refers to the 'View' object.

 

So, your BlogController might have an index() method for instance that is responsible for returning your latest blog post. It might look something like...

 

public function indexAction()
{
  $model = new blogModel;
  $blogs = $model->getLatest(1);
  $this->view = $blogs;
  $this->view->render('viewscripts/blog/index.php');
}

 

Where $this->view refers to your actuial 'View' object (instantiated within the controllers __construct. You don't normally need to call the render() method because the controller should be able to take care of that automatically for you. It also know what view script to render based on what action method is called. This is all usually configurable somewhere.

[KevinM1]

You don't normally need to call the render() method because the controller should be able to take care of that automatically for you.

 

Just to add to this, the most popular convention is for public controller methods to map to view scripts of the same name.  So, a method named index would use a view script named index,php.  A method named showCart would use a view script named showCart.php.  And so on.  CodeIgniter, Kohana, I believe Zend Framework, Ruby on Rails, and ASP.NET MVC all follow this convention.

 

For clarity, let's say you had a couple of controllers:

 

class HomeController extends Controller
{
   public function index()
   {
      // get data from model and render
   }
}

public class CartController extends Controller
{
   public function index()
   {
      // obtain data from model and render
   }
}

 

Two controllers, each with a method named index.  Surely they can't both use the same view script.  This is where the naming convention pays off.

 

Look at the class names.  They follow a convention as well.  SomethingController.  The something is the important part.  It informs the framework where to look for a particular controller's view scripts.  So, the path to the first view script would be path/to/Views/Home/index.php.  Similarly, the second would be path/to/Views/Cart/index.php.  You'll notice that the path supplied to Thorpe's explicit invocation of render is essentially the same.  The exact path name convention  is dependent on the framework - I've been doing a lot of work in ASP.NET MVC lately which is why mine's a hair different than his.  The overall point remains, however.