SmartyView+SmartyHelpers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

SmartyView+SmartyHelpers

Travis Cline

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla

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, "[hidden email]" <[hidden email]>
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla

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" <[hidden email]> 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, "[hidden email]" <[hidden email]>
> 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

Travis Cline

On 11/1/06, sbarre <[hidden email]> wrote:
>
> 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.

I like where you're going with this.
php4 compat would be nice but I really don't think there will be a DRY
solution for php4. I'm personally alright with that.

I'd be inclined to use more reflection and allow even cleaner smarty
calls in the templates:
(i.e. {html func="input" fieldName="User/username" size=30 class="oi oi oi"})

This means cleaning expected parameters from the special array
parameter that is to be generated and passed -- it also requires more
work if there are multiple array parameters.

( Though looking through the helpers api it doesn't look like many
helper methods accept multiple array parameters -- looks like they're
mostly in ajax -- I have a couple ideas about how to tackle this
anyhow. )

Additionally, ReflectionParamater->isArray() is only available >= 5.1
So unless 5.1 is a req. then we have to figure out some workaround
Possible solutions
1. match against common names (htmlAttributes, htmlOptions, options)
  - ew..
2. introduce array marking parameters:
{helper func="method" fieldName="User/username"
new_array="htmlAttributes" size=20 class="freebeer"
new_array2="otherArray" foo="bar" bar="foo}
would call $helper->method("User/username",array('size'=>20,'class'='freebeer'),array('foo'=>'bar','bar'=>'foo'));
  -- assuming function method($fieldName,$htmlAttributes,$otherArray)

Is #2 worth it?  It is a solution for methods accepting multiple arrays as well.

Ultimately I want to find a way to allow that straight native style:
{html func="input" fieldName="User/username" size=30 class="oi oi oi"}

Maybe some combination of ideas presented?

I personally would be happy with:
 - 5.1 reflection to transparently pass all smarty parameters that
don't match in helper method in the methods array parameter
 - allowed direct setting of array parameters with delimiter parsing
 - allowed direct setting using assign_adv (or other array-setting plugin)

Thoughts?

Travis

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

Travis Cline

> I personally would be happy with:
>  - 5.1 reflection to transparently pass all smarty parameters that
> don't match in helper method in the methods array parameter
>  - allowed direct setting of array parameters with delimiter parsing
>  - allowed direct setting using assign_adv (or other array-setting plugin)

Whoops!

My understanding of ReflectionParam->isArray was incorrect it's not
availible in php userspace.  I have an example of name-matching (which
isn't so bad within a single helper, html esp.) and the cleaner
checking of $param->isDefaultValueAvailable() &&
is_array($param->getDefaultValue())

Unfortunately some helper methods have array parameters defined as ' =
null' instead of '= array()'.  This should be a reasonable request to
get into a ticket though.
To test it out now change = null to = array in the relevant function
declarations.

This is approximately what I described above if an array parameter
isn't set directly (and i have param=>value&param=>value parsing
available) then the first unset array parameter is populated with the
remaining parameters passed to the smarty function.

I also implemented assign.

This is largely untested, just wanted to bounce something back.

http://cakeforge.org/snippet/download.php?type=snippet&id=257

Travis

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

Travis Cline

On 11/2/06, Travis Cline <[hidden email]> wrote:
> Whoops!
Whoops again.

A couple problems/enhancements.
If there are parameters after the array parameter that are passed in
the order in the actual call is off.
Hopefully you get the idea, feel free to up a new version seb.

It might make sense to seek default values through reflection if we're
passing in after that -- looking at $html->css and the like.

Travis

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla

Ok I see what you're doing, I like it..

The other idea I had, to avoid doing the collapsed array trick would be
to use the parameter name to identify array elements..   Since all the
parameters are camelCased we could use dashes or underscores (would
dots work?) to identify arrayed values...

So you could have (for example):

{html func="input" fieldName="User/username"
htmlAttributes_class="formInput" htmlAttributes_size="30"}

or something like that.  That might be a bit cleaner in the template,
and I'd lean towards keeping the templates clean and clear and having
more " figurin' " code in the plugin..   When you parse the parameters
you can split on the underscore and build the attributes array that
way..   The reason I'm leaning towards this approach is because the
fake-array method falls apart if any of the array values need to be
arrays themselves.  I don't know of a helper method where this is the
case, but it would be nice to future-proof this code a bit.   I'm
starting a big project and I don't doubt that I will end up writing my
own helpers at some point..

With the underscores method, you can (in theory) keep adding
underscores and in the plugin code parse it down into a
multi-dimensional array if you really had to, and it would not require
changes to the code.

So you could have (this is a bad example but it will do to illustrate
the point):

{html func="input" fieldName="User/username"
htmlAttributes_style_padding="5px" htmlAttributes_style_color="#F6F6F9"
htmlAttributes_size="30"}

In code this would convert to

htmlAttributes => array(
 size => "30"
 style => array(
    padding => "5px",
    color => "#F6F6F9"
  )
)

or something like that..

Lemme try to patch that into your existing helper (which is excellent
so far BTW) and we'll see where it goes..



On Nov 2, 5:18 am, "Travis Cline" <[hidden email]> wrote:

> On 11/2/06, Travis Cline <[hidden email]> wrote:> Whoops!Whoops again.
>
> A couple problems/enhancements.
> If there are parameters after the array parameter that are passed in
> the order in the actual call is off.
> Hopefully you get the idea, feel free to up a new version seb.
>
> It might make sense to seek default values through reflection if we're
> passing in after that -- looking at $html->css and the like.
>
> Travis


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

Travis Cline

On 11/2/06, sbarre <[hidden email]> wrote:
> The other idea I had, to avoid doing the collapsed array trick would be
...
> So you could have (for example):
>
> {html func="input" fieldName="User/username"
> htmlAttributes_class="formInput" htmlAttributes_size="30"}

That's a little more verbose than I'd like.

How about just requiring {assign_adv} or the like for more complex situations?
I think they'll be rare enough requriring them be a bit complex
wouldn't be terrible.
i.e.
{assign_adv var='newarr' value="array('key'=>'value','key'=>'value')"}
{html func="input" fieldName="User/username" class="formInput"
size="30" otherparam=$newarr}

Right now (after I fix the mentioned problem) it's close to a state I
consider usable, the only problem is that you can't use the direct
native style for multiple array options.

It looks like in 1.2 the relevant default values are now correctly 'array()'.

How would you approach the $html->css issue, just require rel be
passed if you want additional parameters?

Travis

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla
In reply to this post by sebzilla

Ok I've got the patch working on the SmartyHtmlHelper class to use the
underscore-delimited attribute names, and to recursively build arrays
from the attributes list if required.

It works pretty sweet...  I'm just trying to sort through how to upload
it to CakeForge now...



On Nov 2, 11:38 am, "sbarre" <[hidden email]> wrote:

> Ok I see what you're doing, I like it..
>
> The other idea I had, to avoid doing the collapsed array trick would be
> to use the parameter name to identify array elements..   Since all the
> parameters are camelCased we could use dashes or underscores (would
> dots work?) to identify arrayed values...
>
> So you could have (for example):
>
> {html func="input" fieldName="User/username"
> htmlAttributes_class="formInput" htmlAttributes_size="30"}
>
> or something like that.  That might be a bit cleaner in the template,
> and I'd lean towards keeping the templates clean and clear and having
> more " figurin' " code in the plugin..   When you parse the parameters
> you can split on the underscore and build the attributes array that
> way..   The reason I'm leaning towards this approach is because the
> fake-array method falls apart if any of the array values need to be
> arrays themselves.  I don't know of a helper method where this is the
> case, but it would be nice to future-proof this code a bit.   I'm
> starting a big project and I don't doubt that I will end up writing my
> own helpers at some point..
>
> With the underscores method, you can (in theory) keep adding
> underscores and in the plugin code parse it down into a
> multi-dimensional array if you really had to, and it would not require
> changes to the code.
>
> So you could have (this is a bad example but it will do to illustrate
> the point):
>
> {html func="input" fieldName="User/username"
> htmlAttributes_style_padding="5px" htmlAttributes_style_color="#F6F6F9"
> htmlAttributes_size="30"}
>
> In code this would convert to
>
> htmlAttributes => array(
>  size => "30"
>  style => array(
>     padding => "5px",
>     color => "#F6F6F9"
>   )
> )
>
> or something like that..
>
> Lemme try to patch that into your existing helper (which is excellent
> so far BTW) and we'll see where it goes..
>
> On Nov 2, 5:18 am, "Travis Cline" <[hidden email]> wrote:
>
> > On 11/2/06, Travis Cline <[hidden email]> wrote:> Whoops!Whoops again.
>
> > A couple problems/enhancements.
> > If there are parameters after the array parameter that are passed in
> > the order in the actual call is off.
> > Hopefully you get the idea, feel free to up a new version seb.
>
> > It might make sense to seek default values through reflection if we're
> > passing in after that -- looking at $html->css and the like.
>
> > Travis


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla
In reply to this post by Travis Cline

On Nov 2, 12:41 pm, "Travis Cline" <[hidden email]> wrote:

> On 11/2/06, sbarre <[hidden email]> wrote:
>
> > The other idea I had, to avoid doing the collapsed array trick would be
> ...
> > So you could have (for example):
>
> > {html func="input" fieldName="User/username"
> > htmlAttributes_class="formInput" htmlAttributes_size="30"}
> That's a little more verbose than I'd like.
>
> How about just requiring {assign_adv} or the like for more complex situations?
> I think they'll be rare enough requriring them be a bit complex
> wouldn't be terrible.
> i.e.
> {assign_adv var='newarr' value="array('key'=>'value','key'=>'value')"}
> {html func="input" fieldName="User/username" class="formInput"
> size="30" otherparam=$newarr}

Yeah again the problem I have with this approach is that it breaks if
you ever need to do multi-dimensional arrays, and it leaves you with no
feasible solution either.

While I can appreciate that arrays as values in parameter arrays are
rare, why impose this restriction when we can avoid it?  I would rather
have one slightly more verbose and flexible tag rather than having to
create potentially multiple {assign_adv} tags prior to my {html} tag,
and also being limited to my array values being scalar only.

To demonstrate, in the testing of my patch to your SmartyHtml Helper I
took this original single-dimension array of params (that came from the
smarty tag):

Array (
  [func] => input,
  [fieldName] => User/username,
  [htmlAttributes_size] => 30,
  [htmlAttributes_style_color] => #f90,
  [htmlAttributes_style_padding] => 4px,
  [htmlAttributes_border_image_x] => 50,
  [htmlAttributes_class] => formInput,
  [htmlAttributes_border_image_y] => 50,
);

and cleanly converted it to:

--------
Array (
    [func] => input
    [fieldName] => User/username
    [htmlAttributes] => Array (
            [size] => 30
            [style] => Array (
                    [color] => #f90
                    [padding] => 4px
                )
            [class] => formInput
            [border] => Array (
                    [image] => Array (
                            [x] => 50
                            [y] => 50
                        )
                )
        )
)
--------
You can see that even the parameters order doesn't matter, and you can
mix them around without risk.

While I can appreciate that it's a bit of an extreme case (and doesn't
actually apply to the input tag), it does demonstrate that the
delimited key name approach does not have nearly as many restrictions
on it as the fake-array assign-in-advance method, and can support any
depth of nested arrays in the parameters list, if required.

I suppose there's no harm in supporting both approaches, although I
ripped out your explode_twice and array-parameter detection code in my
patch of your Helper, since it wasn't needed.. :-)

What do you think?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla
In reply to this post by Travis Cline



On Nov 2, 12:41 pm, "Travis Cline" <[hidden email]> wrote:
>
> How would you approach the $html->css issue, just require rel be
> passed if you want additional parameters?
>

Just to touch on this:

I've implemented the following code to deal with this issue:

foreach ($funcParams as $param) {
        $paramName = $param->getName();
        if (isset($processedParams[$paramName])) {
                $parameters[$paramName] =  $processedParams[$paramName];
        } else {
                if ($param->isDefaultValueAvailable()) {
                        $parameters[$paramName] = $param->getDefaultValue();
                } else if (!$param->isOptional()) {
                        $smarty->trigger_error("SmartyHtml: Error ".$paramName." parameter
is required for method ".$function_name, E_USER_NOTICE);
                } else {
                        $parameters[$paramName] = null;
                }
        }
}

So you can see that when we build our final $parameters array that
we're going to pass to call_user_func_array(), we loop through the
Reflection-supplied list of all the method's parameters, and first we
check to see if our smarty plugin supplied a value for this parameters,
if so, we use it, if not we check if there's a default available, then
we check if it's ok for the parameter to be missing (triggering an
error if it's not) and then finally just setting it to null as a last
resort.

In the end you get a $parameters array that has all of the method's
parameters in order, and you didn't even need to worry about that in
your smarty plugin tag.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla

Here's a Bin of the whole patched SmartyHtmlHelper class if you want to
take a look.  I figured we should sort out how it's going to work
before I submit it to CakeForge as a new version to yours.

http://bin.cakephp.org/view/1918458743



On Nov 2, 1:49 pm, "sbarre" <[hidden email]> wrote:

> On Nov 2, 12:41 pm, "Travis Cline" <[hidden email]> wrote:
>
>
>
> > How would you approach the $html->css issue, just require rel be
> > passed if you want additional parameters?Just to touch on this:
>
> I've implemented the following code to deal with this issue:
>
> foreach ($funcParams as $param) {
>         $paramName = $param->getName();
>         if (isset($processedParams[$paramName])) {
>                 $parameters[$paramName] =  $processedParams[$paramName];
>         } else {
>                 if ($param->isDefaultValueAvailable()) {
>                         $parameters[$paramName] = $param->getDefaultValue();
>                 } else if (!$param->isOptional()) {
>                         $smarty->trigger_error("SmartyHtml: Error ".$paramName." parameter
> is required for method ".$function_name, E_USER_NOTICE);
>                 } else {
>                         $parameters[$paramName] = null;
>                 }
>         }
>
> }So you can see that when we build our final $parameters array that
> we're going to pass to call_user_func_array(), we loop through the
> Reflection-supplied list of all the method's parameters, and first we
> check to see if our smarty plugin supplied a value for this parameters,
> if so, we use it, if not we check if there's a default available, then
> we check if it's ok for the parameter to be missing (triggering an
> error if it's not) and then finally just setting it to null as a last
> resort.
>
> In the end you get a $parameters array that has all of the method's
> parameters in order, and you didn't even need to worry about that in
> your smarty plugin tag.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

Travis Cline

I fixed up the issues I mentioned and had added defaultparameter passing.
I'll post the new version up there in a bit (away from my dev
environment right now).

I'd like to figure out a way to combine the ideas.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

Erich C. Beyrent

Travis Cline wrote:
> I fixed up the issues I mentioned and had added defaultparameter passing.
> I'll post the new version up there in a bit (away from my dev
> environment right now).
>
> I'd like to figure out a way to combine the ideas.
>
> >
>  
So if I want to use Smarty with CakePHP, I must be using PHP5, or I am
stuck with the thtml solution?  Do you plan on making this PHP4 compatible?

-Erich-

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

René-23
In reply to this post by sebzilla

I'm using Smarty for a while now and got around the array issue by this
compiler helper:

function smarty_compiler_helper($tag_attrs, &$compiler)
{
        $args = explode('->', $tag_attrs);
        $arg0 = $args[0];
        unset($args[0]);
        $arg1 = implode('->', $args);
        $arg1 = preg_replace('/\$(\w+)/', '$this->_tpl_vars[\'\1\']', $arg1);
        return('echo $this->_tpl_vars[\'' . $arg0 . '\']->' . $arg1 .';');
}

With this SmartyPlugin you can use CakePHP helpers like this:
{helper html->input('Model/field', Array('tabindex' => 1))}

I know this is neither perfect nor clean, but it does the job.

Greetings,
René


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

sebzilla

That's pretty slick actually..  I never really thought about extending
the compiler to accept some sort of native array parameter..

I'm a broken record on this, but I would have to extend this to support
nested arrays like:

{helper html->select('Model/field', Array('tabindex' => 1, 'options' =>
Array(0 => 'No', 1 => 'Yes'), 'class' => 'selector' ))}

It's not my fault I like run-time multi-dimensional data structures..
:-)   I just find them clean and easy to understand for template
designers..

On Nov 3, 9:29 am, "René" <[hidden email]> wrote:

> I'm using Smarty for a while now and got around the array issue by this
> compiler helper:
>
> function smarty_compiler_helper($tag_attrs, &$compiler)
> {
>         $args = explode('->', $tag_attrs);
>         $arg0 = $args[0];
>         unset($args[0]);
>         $arg1 = implode('->', $args);
>         $arg1 = preg_replace('/\$(\w+)/', '$this->_tpl_vars[\'\1\']', $arg1);
>         return('echo $this->_tpl_vars[\'' . $arg0 . '\']->' . $arg1 .';');
>
> }With this SmartyPlugin you can use CakePHP helpers like this:
> {helper html->input('Model/field', Array('tabindex' => 1))}
>
> I know this is neither perfect nor clean, but it does the job.
>
> Greetings,
> René


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: SmartyView+SmartyHelpers

Travis Cline

On 11/3/06, sbarre <[hidden email]> wrote:
>
> That's pretty slick actually..  I never really thought about extending
> the compiler to accept some sort of native array parameter..
>
> I'm a broken record on this, but I would have to extend this to support
> nested arrays like:
>
> {helper html->select('Model/field', Array('tabindex' => 1, 'options' =>
> Array(0 => 'No', 1 => 'Yes'), 'class' => 'selector' ))}
I'd like to see multi-level support with the compiler plugin as well
-- I think that approach is the most viable for php4 users.

Rene, could you post that as a snippet so I can point to it in the
SmartyView bakery article?


Sorry about the delay on getting things out.
I've taken in your changes sbarre but have retained my functionality as well.
For example:
{html func=image path='url/to/image.png' class='image old' border='0'}
or
{html func=radio fieldName='Model/field' options_value1='option1'
options_value2='option2' inbetween='<hr />' class='radioclass'}
You can also use direct assignment from controller or from
assign_adv/assign_assoc as well.


http://cakeforge.org/snippet/detail.php?type=package&id=31
http://cakeforge.org/snippet/download.php?type=snippet&id=277

I also added an optional __show_call=true parameter to var_dump
$parameters before the call.

I put some initial doc here (feel free to email me with
additions/changes to the article):
http://bakery.cakephp.org/articles/view/138

Travis

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "Cake PHP" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---