On Nov 2, 12:41 pm, "Travis Cline" <[EMAIL PROTECTED]> wrote:
> On 11/2/06, sbarre <[EMAIL PROTECTED]> 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 [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
-~----------~----~----~----~------~----~------~--~---
