Development

#374 (Move all helpers inside classes for organization, namespace conflict prevention)

You must first sign up to be able to contribute.

Ticket #374 (closed enhancement: wontfix)

Opened 2 years ago

Last modified 4 months ago

Move all helpers inside classes for organization, namespace conflict prevention

Reported by: synace Assigned to:
Priority: minor Milestone:
Component: askeet Version: 0.6.1
Keywords: Cc:
Qualification: Unreviewed

Description

for example,

debugHelper.php becomes: debugHelper.class.php

and gets wrapped in:

class debugHelper
{
//insert original debugHelper functions here
}

For backwards compatibility, 'use_helper' will load all the functions into the current scope for execution/use.

function use_helper($helperName)
{
	//insert original use_helper code here
	foreach ( get_class_methods($helperName) as $methodName )
	{
		eval('function ' . $methodName . '() { $args = func_get_args(); return call_user_func_array(array("' . $helperName. '", "' . $methodName . '"), $args); }');
	}
}

eventually then, in a later version, helperHelper could be phased out.

Change History

03/30/06 01:14:05 changed by synace

the autoload function would also have to be updated to look in the helpers directory.

and while we're at it, we might as well rename (read: add aliases) to all functions in camelCaseFormat instead of underscore_separated_format.

so, we could then, inside a template, call:

<?php echo numberHelper::formatNumber('123456890'); ?>

and know that we're using the numberHelper right away, and not have to worry about some other helper that tried to define a 'format_number' function.

03/30/06 01:29:41 changed by anonymous

nevermind needing to update autoload I just forgot to clear my cache :)

So, basically, this is a ticket to: move all helper functions into classes with the option of backwards capability...

03/30/06 06:50:26 changed by simonbun

I've thought about making helpers into objects as well, and i like the idea. Mainly for ease of extending certain helpers instead of copying code and prepending them with 'my'.

The only problem is readability of template code. If you load every helper method statically, it can get messy. JavascriptHelper::input_auto_complete_tag(), ValidationHelper::form_has_error(), and even UrlHelper::link_to() would bug me.

Maybe instead of calling the methods statically, each helper that is set to load can be combined into one class and instantiated automatically? Something like $sfHelper->formatNumber(); (or even $sfH->formatNumber()). Then to add helpers in the template (like use_helper('Javascript')), one can use $sfH->load('Javascript'); or something similar.

Its a bit of a pickle this one...But unless someone can think of a really good pro-argument, i think its better to leave things as they are concerning helpers.

03/30/06 21:12:45 changed by synace

re: readability:

IMO a statically called method is more readable because it tells you WHERE the method is coming from.

I work in a team of 3. 1 'designer' -> does photoshop layouts, graphics, buttons, etc. 1 'front-end coder' -> does html/css layouts, all GUI related code 1 'programmer' -> does back-end programming, data model, buisness related xml, javascript

my template coder will be responsible for decorating the data as they see fit. that means they have to know the helpers. there's no way around it. unless we come up with another language (a-la-smarty) but that's just another thing to learn, and another layer of speed deficiency.

this way, real programmers can build, maintain and extend helpers accordingly, and then template coders can use them by understanding 1 easy php5 concept (static class method access).

other than that, you end up with the same problem php faces, a TON of functions in the global namespace, and trying to guess where the function comes from.

to a template coder, there's no difference between

{section name=i loop=$people}
{/section}

and

<?php foreach( $people as $person ): ?>
<?php endforeach; ?>

and there's surely no difference between

<?php echo dateHelper::formateDate($myDate, 'F'); ?>

and

<?php echo format_date($myDate, 'F'); ?>

except that you KNOW that formatDate is FROM the dateHelper (aka, they can go open the 'dateHelper' book and look at the methods and their parameters

This also allows the added benefit of adding a sfHelper class to build base functionality into.

....This has been debated 50 different ways. "PHP" vs "TEMPLATE LANGUAGE". symfony has clearly gone the route of PHP. Let's embrace that and get rid of the functions flooding the namespace so that every part of symfony can join in on the organizational bliss.

04/01/06 16:14:28 changed by simonbun

You're right, it would be clearer where the functions come from, but i'm not sure it would make things easier per se. My point however was that it would make the use of helpers quite verbose to write, and would clutter up the template.

I'm interested in what other people think if this issue.

04/10/06 11:44:40 changed by fabien

  • milestone changed from 0.6.2 to 1.0.0.

08/22/06 22:21:54 changed by fabien

  • milestone changed from 0.6.4 to post-1.0.

12/27/07 00:02:22 changed by FabianLange

  • status changed from new to closed.
  • resolution set to wontfix.
  • component set to askeet.
  • qualification set to Unreviewed.

Ill close this ancient ticket. in 1.0.x this stays as it is. for 1.1 This will be gradually done

05/10/08 22:25:24 changed by fabien

  • milestone deleted.