CMSMS | CMS Made Simple

CMSMS 2.0 has a few main goals. One of them is adding some sorely needed features. Another is code cleanup. However, one of the major ones in my opinion is making it easier to develop modules.

One of the things that has annoyed me about the whole smarty thing with modules is that you’re writing EVERYTHING to smarty and then spitting it all back out from strings in your smarty template. It’s almost not worth it, especially when you have lines of code just to set up for translated strings. Yuck!

Anyone who has made a module or has at least looked at module code can see how tedious this is… well, it’s all about to change.

Firstly, let me show you an example of a smarty setup now. This comes directly from my News rewrite. It’s in the admin section where you edit a category. I’ve removed a few lines of code, but the premise is there..

$catid = coalesce_key($params, 'catid', '');
$category = cmsms()->news_category->find_by_id($catid);
 
$smarty->assign_by_ref('category', $category);
 
#Display template
$this->smarty->assign('parents', $this->CreateParentDropdown($id, $catid, $category->parent_id));
$this->smarty->assign('hidden', 
		      $this->CreateInputHidden($id, 'catid', $catid).
		      $this->CreateInputHidden($id,'origname',$name));
$this->smarty->assign('submit', $this->CreateInputSubmit($id, 'submit', lang('submit')));
$this->smarty->assign('cancel', $this->CreateInputSubmit($id, 'cancel', lang('cancel')));
 
$smarty->assign('action', 'editcategory');
 
echo $this->process_template('editcategory.tpl', $id, $returnid);

I’ve removed the code that saves the category that fits into the middle. I also have a CreateInputSubmit and CreateInputHidden things that will go away before the final release. However, I used this to prove a point…

Here is the associated smarty template

{validation_errors for=$category}
 
{mod_form action=$action}
	<div class="pageoverflow">
		<p class="pagetext">*{mod_label name='category[name]' value='name' translate=true}:</p>
		<p class="pageinput">{mod_textbox name='category[name]' value=$category->name size='20' maxlength='255'}</p>
	</div>
	<div class="pageoverflow">
		<p class="pagetext">{mod_label name='category[parent_id]' value='parent' translate=true}:</p>
		<p class="pageinput">{mod_dropdown name='category[parent_id]' selected_value=$category->parent_id items=$parents}</p>
	</div>
	<div class="pageoverflow">
		<p class="pagetext">&nbsp;</p>
		<p class="pageinput">{$hidden}{$submit}{$cancel}</p>
	</div>
{/mod_form}

(Again, pretend the $submit and $cancel aren’t there… that’s yet to come)

As you can see, we have smarty plugins to wrap various methods in the module API. {mod_form} for CreateFormStart, {mod_label} for CreateInputLabel, etc. They retain all of the available parameters, except that the beauty is that you don’t have to worry about passing around the $id and $return_id. It’s all handled behind the scenes now.

{validation_errors} is a slick plugin that displays errors that might occur during the validation before an ORMed object’s save() method. If save fails, validation_errors will pick up the errors and display them. This makes for very consistent error messages throughout the system. It also means that you don’t have to do any validation in your screens, just in the ORM object.

Also, notice another thing I’m doing here. category[name], category[parent_id], etc. This allows me to get all of the parameters destined to be for the category object into one hash after the form is submitted. In fact, I name them exactly the same as the parameters in the object itself. Why? Well, here is the part that saves the object… assume that I have $category already set with the find_by_id we saw earlier.

if (isset($params['category']))
{
	$category->update_parameters($params['category']);
	if ($category->save())
	{
		$this->UpdateHierarchyPositions();
 
		$params = array('tab_message'=> 'categoryupdated', 'active_tab' => 'categories');
		$this->Redirect($id, 'defaultadmin', $returnid, $params);
	}
}

Basically, we have 2 lines of code to do all of the updating of the object and saving it. update_parameters takes all of my category[] fields in the form and fills the corresponding parameters in the object, and save(), well, saves. If the save fails, then we continue on as normal, knowing that {validation_errors} will display the reason(s) why the save failed.

All in all, these changes easily reduce your code by 50%, if not more. In the case of edit_category, we went from 102 lines to 42. It’s less memory intensive, uses smarty in a more correct manner, and is just plain old faster… faster to develop and faster to run.

Bookmark to:

This entry was posted on Wednesday, January 17th, 2007 at 12:00 pm and is filed under Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.