Ok I've done a little bit of digging on PHP5's Reflection API, and I've
figured out the following:
By inspecting a helper's methods - for this example we'll use
$html->input() - we can determine the names of the parameters that a
given method in the helper is expecting.
Based on this information, in our smarty plugin (which takes 2
parameters, the array of params and a ref to the smarty object), we
could do the following:
First, In the smarty template we have a tag like this:
{html func="input" fieldName="User/username"
htmlAttributes="class=>formInput&size=>30"}
In the plugin code that the above tag maps to, we would have:
function smarty_html_wrapper($params,$smarty) {
$function_name = $params['func'];
$parameters = array();
$html = $smarty->view->html; // copy our helper for convenience (this
might be wrong - whatever)
// here we need some code to loop through and "massage" the parameters,
// in order to convert, for example, the htmlAttributes "fake-array"
into a real array,
// and do anything else..
[... blah blah ...]
// parameters all better, moving on...
$htmlReflector = new ReflectionClass($html);
if ($htmlReflector->hasMethod($func)) { // quick sanity check
$funcReflector = $htmlReflector->getMethod($func);
$funcParams = $funcReflector->getParameters(); // returns an array
of parameter names
foreach ($funcParams as $param) {
$parameters[] = $params[$param->getName()];
}
call_user_func_array(array($html,$function_name),$parameters);
} else {
// output some kind of error if the function doesn't exist
}
} // end smarty plugin function
Sorry for the messy markup I'm in a bit of a hurry. I think this, or
maybe something like this (I have not tested this code, I wrote it in
the Google Groups window), would work for creating a single per-helper
plugin (and in fact it would be the same plugin for all the helpers
just with a different name) that doesn't need to know all the details
of all the methods that exist in the helper class itself.. I love
D-R-Y!
Any thoughts on this? Travis? You want to work with me on getting
this going? I'd love to switch back to using Smarty instead of THTML..
Having all that PHP code in my views makes me feel dirty.. :-)
seb
On Nov 1, 5:21 pm, "sbarre" <[EMAIL PROTECTED]> wrote:
> So just to clarify, do you plan on writing smarty plugins for every
> method in every helper?
>
> I went through the same steps that you did, based on my desire to use
> Smarty instead of THTML (mostly because I may have untrusted template
> authors at some point - and also because I've written a custom Smarty
> wrapper that implements namespaces and directory-based fallback and
> better fragment handling and I wanted to use it).
>
> But when I looked through the helpers I realized that writing a plugin
> for each method in each helper was basically a waste of time.
>
> The idea of {html_input field="User/username" class="formInput"
> size="30"} is nice but requires a plugin-per-method for each helper...
> Bleh..
>
> I even toyed around with the idea of a plugin for each helper and
> deriving the method name via a parameter , something like {html
> func="input" field="User/username" ...} but again mapping the plugin
> parameters to the variety of helper methods parameters just didn't seem
> worth the effort unfortunately..
>
> If the helpers all accepted parameters as an array instead it would be
> easy, but they don't, and many of them take a mix of arrays and
> scalars, so there would have to be explicit mapping happening in the
> plugin (correct me if I'm wrong) and that violates the
> Dont-Repeat-Yourself approach a little too much for me..
>
> I would love to find a solution to this (and would even collaborate on
> one if it was worthwhile) and move back to Smarty, especially since I
> am still early in development, but I don't see a reasonable approach.
>
> This gives me an idea actually, Travis, do you need to be backwards
> compatible to PHP4 or are you ok if this solution was PHP-5 only?
>
> I am thinking we could use PHP5's reflection API to map parameters to
> the helper methods, and use PHP's magic methods (__call() etc..) to map
> from the plugin to the helper..
>
> Thoughts?
>
> On Oct 31, 3:59 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
> > There are several messages floating around without great answers about
> > Smarty integration and I wanted to let other know about some
> > developments.
>
> > A few days back I broke away from development on a homegrown mvc
> > framework and shifted to cake (decision was hard but the transition has
> > been smooth).
>
> > I know all the arguments against using Smarty, no need to reiterate. I
> > think it is arguable that with a properly configured Smarty setup (with
> > caching) you can rival/beat straight thtml calls.
> > But regardless, there are people that will sacrifice a bit of
> > performance to be able to use Smarty.
>
> > I've updated phpnut's SmartyView example to include:
> > - thtml fallback for views (increases the filesize as it overrides
> > _getViewFileName -- adding 4 lines) -- I talked to phpnut about
> > allowing app/views thtml fallback in core (already does for libs/views)
> > but he refused (somewhat understandably, though I think it can be
> > accomplished cleanly).
> > - I also added the ability to place smarty plugins in
> > views/smarty_plugins instead of w/smarty in /vendor.
> > - Additionally I coded brief examples of providing smarty function
> > wrapping of helper class methods to allow 'native' smarty calls.
>
> > This gets around the 'array(' issue in smarty templates, allowing you
> > to do something like this:
> > {html_input fieldName=User/username class="test" size=30}
> > (vs)
> > <?php echo $html->input('User/username',
> > array('class'=>'test','size'=30); ?>
> > (or even uglier previous smarty method)
>
> > Other than expanding the wrappers I have a short todo that will
> > increase functionality/usability but I think it's at an acceptable
> > state now.
>
> > No need for the 'but it's another layer!!!111' comments, we've been
> > through them already =)
>
> > I personally don't mind much how the vanilla template styles look in
> > most cases but this helped soften the fall from moving away from my
> > prior work.
>
> > See:http://cakeforge.org/snippet/detail.php?type=package&id=30(SmartyView
> > +
> > SmartyHelpers)http://cakeforge.org/snippet/detail.php?type=snippet&id=6(Straight
> > SmartyView)
> > Also, placed a bit of doc
> > here:http://bakery.cakephp.org/articles/view/124(made a small edit, went
> > back to moderation).
>
> > Travis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---
