Skip to content

Views

Jump to bottom Edit New page
dbald edited this page Sep 16, 2010 · 3 revisions

Views

Home > Views

Views are where static content meets code. There are some rules as to where Evergreen will look for a view, based on your controller and method names.

Here are some examples:

<?php
/* /controllers/main.php */
public function index() {
	// code
}
?>

Will look for this file:

/views/main/index.php

Same as this method in this file:

<?php
/* /controllers/archives.php */
public function march09() {
	// code
}
?>

Will look for this file:

/views/archives/march09.php

You can force methods to look into other folders and at other files when you use the _getView function like this:

<?php
/* /controllers/software.php */
public function games() {
	$this->_getView('motherboards', 'hardware', true);
}
?>

That method would normally look for this file:

/views/products/games.php

But because we’re using the third option, override, it will look here instead:

/views/hardware/motherboards.php

If you didn’t use the override parameter, it would load both views.

This is how you load in snippets, for example, I have the file:

/views/layouts/tier.1.php

And inside I’ve got a code block, paraphrased:

<html>
	<head>
		<title>Page</title>
	</head>
	<body>
		<?php
			
			$this->_getView('header', 'layouts');
			
			echo $this->_getViewContent();
			
			$this->_getView('footer', 'layouts');
		?>
	</body>
</html>

Say that tier.1.php is set as your layout, whatever method you are loading ends up where _getViewContent function is echo’d, and we load in the header and footer before it for easy editing.

You’ll want to do most, of your database calls and additional content manipulating inside the controllers, but to get the variables, you’ll have to put them in the right scope. Same as calling $this→_getView() which comes from /lib/controller.class.php, we can add scope our method variables using $this which will allow them to be used inside the layouts and views.

<?php
/* /controllers/main.php */
public function index() {
	
	$dbData = database call;
	$this->dbData = $dbData;
}
?>
/* /views/main/index.php */
...
<div>
	<?php
		
		foreach ($dbData as $data) {
			
			// this will cause an error because that variable doesn't exist in this page's scope.
		}
		
		foreach ($this->dbData as $data) {
			
			// correct scoping because you're calling the variable from the controller above this method.
		}
	?>
</div>
...

Designer Tags

The Designer tags are a set of useful tags that give you a path, useable in views and layouts. The benefit of these tags is that you dont have to know anything about code to use them.

Here is a list of the tags along with descriptions:

1. [current] – This will give you the current view you are using.

<?php
/* /controllers/products.php */
public function software() {
	//
}
?>

If you called current here, the path would show this:

/products/software

2. [site] – This will give you the URL root, so if the root of your project was located at http://localhost/project-name, then you’d see this path:

/project-name

This tag would then always show that path, even if you’re twenty pages deep. This would be / if your project is at root. This is used for things like URL’s as this will always point you to the correct page even when not using mod_rewrite.

3. [skin] – This will give you the root of the “public” folder. Once again your framework is located at http://localhost/project-name, you’d see this:

/project-name/public

Same as [site], this will get you to the root “public” from wherever you are.

4. [root] – This will provide you the absolute URL to the root of the framework as used by files such as images. Using this for files will make sure that even if you are not using mod_rewrite your files will always point to the correct location. but if you have a special case where there is some rewriting happening, then this tag will give you t he

5. [branch.site] – If you use this in a branch, it will give you the URL path to that branch.

<?php
/* /branches/admin/controllers/pages.php */
public function edit() {
	//
}

/branches/admin/controllers/view/pages/edit.php
?>

Instead of giving you this:

/branches/admin/

It gives you:

/admin

This is because we don’t want the browser to see or care that we’re in a branch, we keep it there for organization. Once again, this will always give you this path, no matter where you are in the branch.

6. [branch.root] – This will give you the filesystem root. Using the same controllers and views as above, we would see this:

/branches/admin/

Will also give you the same path as long as you’re in the branch.

7. [branch.skin] – Similar to the normal [skin] tag, except it will look in the branch “public” folder. Same example as above:

/branches/admin/public

Notice how it gives you the filesystem path. This is because the browser does need to see the full path to get to actual files. Will give the same no matter where in the branch.

One thing to note about all Designer tags, is that it only processes them on views and only on loading that view. That means you can’t use them in CSS or JS files, as well as manipulating data with JS after the page is loaded.

Designer tags are also available for each of the items in URI.map such as [controller] or[view]. As you change the URI.map by adding or deleting items those changes will be reflected in the designer tags.

Form Handler

The Form Handler is a helpful addition to the framework that allows you to have field data populated automatically without having to do it on individual inputs, selects, and textareas in your form.

Using the Form Handler is as easy as putting some additional attributes into your form tag. The attributes are:

1. update=""
Adding this along with the value as a PHP variable will use that variable to try and fill in the fields. Generally, you would use $_POST to pull whatever PHP grabs normally. This works best, because that variable is an associative array of the values in the form from the previous post.

The main purpose of this is to automatically update the form with the data the use posted if there is an error, so they don’t have to go back in their browser, which is unreliable, and we don’t have to put them in manually one-by-one.

2. default=""
Using this one with a value of a PHP variable is similar to the update, except this one will be for when loading a form, and you already have data for it. The best example is for “edit” forms where the data exists, and you want to fill in fields automatically. When using the framework, when pulling an entry from a DB for editing, you can use the getProperties() function, and when scoped correctly, you can use that variable as the default, as it will be a correctly structured associative array. Here’s an example:

<?php
$dbData = a single database entry;
$this->props = $dbData->getProperties();
?>

Now in your form tag, you would use the default=“$this→props” attribute to auto-fill the fields.

These values are overwritten when using the update="" attribute after a submit that goes back to the form.

By default password fields arent autopulated by the update or default attributes for security. To override this for a password field you would add an attribute into the input tag for your password field as described below.

1. autopopulate=“true”

Public

This folder is for anything, and I mean anything, but normally, you would set this up as the folder that would hold your images, CSS, and JS. The one difference for everything in this folder is that there are no requirements on naming or structure.

Add a custom footer
Add a custom sidebar
Clone this wiki locally