When to use a Helper?

[Myke623]

I'm wanting to post-format some data extracted from the database.

I could either iterate through the returned data in the Controller before passing it to the view, or, use a custom helper directly in the view to do any fancy formatting.

Is there a general rule of thumb of when I should consider creating my own helper? Would it be recommended in this particular case?

 

[Aayush]

It's a matter of preference, I usually send the data to the template as clean and processed I can send, then I format it via helpers if needed.

I am not sure if any of these options has any effect on speed of execution though.

 

[Myke623]

Thanks for the reply, but yeah, I was mainly interested in finding out if there was any notable difference in performance.

 

[tyteen4a03]

There are no performance differences just because you decide to place the class in class A instead of class B.

Helper classes should be used for static functions. If it ever needs to access the DB (other than the cache), it probably goes into a Model. It should also be reusable.

 

[Jaxel]

I've only ever used a helper for one specific reason... and thats to check for file existance in thumbnails for my XenMedio addon... For instance:

<img src="{xen:helper medio, $media}" alt="{$media.media_title}" />

In the past, I had this hard-coded as a something along the lines of:

<img src="/data/media/{$media.media_id}.jpg" alt="{$media.media_title}" />

However, this caused 2 issues...

1. Hard-coding in the url to the thumbnail made the mod incompatible with websites that used external CDNs.
2. If for some reason, thumbnail generation failed, or the thumbnail was missing, it would display a broken image.

Switching all this all to a helper allowed me to designate the url redirected to the CDN, and it also allowed me to check for file existence. If the file doesn't exist, it returns the url redirected to a default empty thumbnail.

If using a helper doesn't solve a specific problem; then I don't see a reason to waste your time setting one up. If it ain't broke, don't fix it.