Smarty

[volkris]

I'd like to be able to {assign} to arrays somehow, just like one can {assign} to normal variables.

In my current project I wanted to use the various html_ functions to display information, but where these functions wanted arrays as input (for the loop argument of html_table, for example), I needed some array elements to be the output of the capture function.

So perhaps some kind of {assign_array $var1 $var2 $var3 ...} is in order?

It seems to me that passing an array to these html_ functions is a smart way to do these things, but often times the input data really needs to be generated by other parts of the template....

[boots]

Hi. There are various ways of doing this (even here at the forums there are demonstrations) and IIRC a custom plugin function was submitted to the wiki that does this.

[volkris]

Well yes, I created a function that did nothing but set assign $params as a new array. I felt really silly doing it, too.

And I did search all throughout the discussion list looking for people trying to do things similar to what I needed to do, because I really didn't want to do a custom function for that.

What it comes down to is that arrays really do fit into what I percieve to be the philosophy of Smarty. It sounds like you're so afraid of abuse of the feature that you'd throw away the improvements it would bring when generating complex pages.

It's absolutely correct for functions involving lists to accept arrays--that's just good design--but smarty needs to be able to format and sometimes generate things like code for radio buttons inside of these arrays. It has nothing to do with raw data in these cases; it has to do with html's natural proclivity toward nesting and a need to pass formal variables in a structured way.

Just because you're using an array doesn't mean you're necessarily doing any heavy lifting. I agree that you shouldn't be sorting in a template, but using arrays as basic containers has real benefits in terms of usability and readability of the code. This is, after all, how plain variables are used...

Arrays are useful for the same reasons as regular variables, and either can be abused. Things like {assign} and {capture} show that smarty accepts the usefulness of dynamically assigning to plain variables despite the potential for abuse, so why not arrays? In a system like Smarty where data is passed as arguments to functions, this functionality becomes extremely important.

[boots]

Hi again!

Well, I certainly don't disagree with you. Never-the-less, you have seen first-hand how trivial it is to implement such functionality in a custom plugin and further, how it enables you to use syntax of your choosing. (Note that getting a concensus on HOW to implement array assignment is likely not an easy thing.) Thus, advanced users can easily get this functionality at the cost of a rather minute plugin function.

I'm not at all afraid of abusing the feature, by-the-way, but I am all for keeping the core distribution as small as possible. There are MANY useful but somewhat escoteric features that have been rejected by the core development team for this very reason. In this case, there is hardly a loss since the Smarty API makes it simple to implement the desired functionality.

That said, if you have created a plugin that you would like to share with the community then please post it in the plugin forum. If you think your plugin (or patch) is worthy of inclusion in the main distribution, I suggest that you submit it to the smarty-dev mailing list.

I also suggest this thread.

Greetings.

[messju]

chdir to your plugins-dir and do
perl -pe 's|assign|append|g' <function.assign.php >function.append.php

use {append} in your templates to construct your arrays then

scnr

[boots]

@messju: perl, eh?

Say, wouldn't this imply that {assign} should be sufficient or is that your funny bone showing?

[messju]

@boots:
oldschool guys would say perl is overkill here and would use sed, of course

assign isn't sufficient to build arrays in smarty, but $smarty->assign() is very similar to $smarty->append(). so, you just have to copy function.append.php to function.assign.php and replace all occurences of "assign" in there to "append". thats what the line above does and it gives you a plugin that can append values to arrays.

i just wanted to confirm your statement, that it is a minute work to get such a plugin

[boots]

Gee--I didn't think about $smarty->append().

As always, super clever Messju!!

Yes, sed! I guess I'm just a little surprised that you didn't use the PHP CLI even though it is a bit less succint.

A funny aside about English ambiguity: I intended 'minute' as in small-in-size, not as in a unit of time equal to 1/60 of an hour. Indeed, I think your solution takes only seconds!

[volkris]

Stupid Internet Explorer ate my oh so carefully crafted response. Looks like from now on I'm installing Firebird no matter WHOSE computer I'm on at work.

Oh well. Take two.

Boots, yes it was easy to implement that plugin, but it was a very dirty hack. It would be MUCH more elegant if such functionality was already in the core of Smarty, or at least in a base plugin.

See, in a couple of weeks I'm going to have to explain to my boss why I chose to use Smarty when such a fundamental feature has to be implemented by a dirty hack. It's just not going to be painting the system in a very good light.

This sort of basic array handling isn't just some esoteric feature, it should be a fundamental part of the system's infrastructure. After all, you pass these things to other functions as a matter of routine.

messju, I forgot about append too. This sounds like it'll do what I want to do; I'll try it out later tonight.

Even with append around there is still need for improvement on this, though. First of all, the documentation needs to be clear about what the suggested method of dynamically handling arrays actually is, whether it be assign or append, or whatever. I might suggest that this could be a jumping off point for a quick lecture on what type of processing to keep out of templates, too.

But I think Smarty can do better with its handling of arrays anyway. How about modifying assign so that it recognises the normal array bracket notation? That's kind of an accepted and php-like way of doing things.

Using the append function as THE way to create and assign arrays just doesn't fit in perfectly with the rest of the package. It just isn't analogous enough to assign and the other variable and array treatments.

I waxed further about this in the first version of this reply, but Smarty has just a couple of rough edges that keep it from really being corporately acceptable, if you know what I mean. Weak and somewhat inconsistent array handling is just one of these points. While it seems to be a really good framework, it just needs to fill in a couple of small holes before I could be confident presenting it to, say, my boss.[/code]

[boots]

Volkris, thanks for taking the time to write--twice!!

Again, I'm not disagreeing with you; however, perhaps you would care to give a concrete example of what you are trying to do? I have been using Smarty in both standard and very atypical ways and I can honestly say that I don't see a need for this in the core. I'm a firm believer that what you pass to Smarty should be processed enough so that Smarty only need to do the minimum amount of work to transform it into your output. In other words, building arrays is not the type of thing that designers are expected to do when using Smarty--that's what the application designer is supposed to do. When those roles are filled by the same person, the tempation to mix the efforts can be great.

FWIW, I am listening, even though my opinion really doesn't count for all that much when it comes to implementation as the Smarty tree does not belong to me . Still, if your examples are persuasive I will certainly help champion the cause. Further, if you presented some solid code to implement your idea you will likely get a lot more traction with the developers.

Also, do you really think that implementing array handling in a custom plugin is a dirty hack? The API is there just so that you can extend Smarty to fit your needs. When would you say a custom plugin not a hack? Remember, *most* Smarty users don't need (and shouldn't have access to) the feature you are so keen on.

Just remember to smile when your boss asks you how you are managing to be so productive

[volkris]

You know, boots, in projects like Smarty everyone involved has it in his best interest to hash out ideas. Smarty developers want to make the best Smarty they can make (out of altruism or whatever motivates them), and end users have a chance to guide the evolution in directions better for themselves. We're all being selfish when taking the time for these discussions

And you know in my particular case perhaps there was an accepted way of doing things. Perhaps the Smarty developers would have called it a case for using multiple templates, having the php file generate the array from many different template files or, perhaps, different parts of the same file through control statements. While I don't think this is very good from a usability and maintenance statdpoints, it's at least worth knowing what the devs have in mind.

So, here's what I needed to do:
I needed to have a form with a group of radio buttons. Easy! I used {html_radios}. It worked great, give it an array containing the radio button choices and it just works.

One problem, though. In three of the six choices I needed to have a drop down box, and I really wanted to use {html_options} to make the box for me.

You see where I'm going. The easiest thing in the world would have been to pass an array of options to {html_options} and pass the output of that to the array of values going into {html_radios}. Dropping back into PHP to do this quick packaging should have been unnecessary, and an array here serves only to funnel values into the {html_options}. As I said, it's part of the infrastructure. It's exactly the same thing as dynamically assigning a variable to pass to a function and should be treated in almost the exact same way, philosophy wise.

There are no doubt many other examples of this same thing. Basically every time you want to nest template generated code into another template generated structure that involves lists you'll hit the same thing.

As another example, say I wanted to put some radio buttons inside of a cell or two of a table. The intuitive way to do it would be to generate the radio buttons using {html_radios} and add that to the array containing the rest of the cells' values. Passing that array to the {html_table} would have you where you want to get. And again, it's the same as when you might assign a template generated string to a variable, only to pass it to {html_table} as the trailpad parameter. It makes perfect sense and you wouldn't want to do it any other way.

And yes, I really think creating a function that returns nothing more than one of its parameters is a dirty hack. I basically had a function that didn't do anything, dropping me out of the template processing but not doing any php processing instead. And now whenever I want to change servers I have to remember to copy over that blank function when I go, quite a hassle for not doing any processing. I don't know if this interruption in template processing causes any performance hit, but I can't imagine it's a good thing on that front either.

[boots]

Well that is an interesting use. I certainly see why you want to build arrays in template and I give a nod to your description of hacky plugins (but I disagree with your assessment in that case and the "having to remember to copy the function" bit really doesn't fly). Further, for such a simple feature, it is nearly not worth the debate except that you raise some nice issues so I will try to carry on at least one more time

It appears that you are in an environment where your designers are quite happy manipulating and rearranging data structures. That's cool. It also appears your team is comfortable with the concept that Smarty can be used as a language of sorts in its own right. I have stated many reasons why I find that acceptable in other threads (although in those cases, it is typically to support extensive customizations that create application specific mini-languages). Still, I do not see that as a core use and in principle I can not (and do not) recommend that usage.

Instead of rehashing why I think the core should remain simple, I will look at the issue you raise using alternate approaches to the one described.

One approach is to consider what you are using the html_options and html_radios for and also what they are intended for. Of course, these are both plugins shipped with Smarty and are attractive since they are immediately useful while also rather flexible. Never-the-less, they have limitations. Evidently, the plugins were not designed to fit the pattern you are using and considering that they are plugins--that is, add-on functionality--there is merit in looking at ways to either re-implement the plugins to meet your needs or to create a new custom plugin for your custom use (or to re-evaluate your usage pattern). The important point is that in doing so, you put the onus on your application programmer to ensure that the data structures are correct and more importantly, the actual transformation code is correct.

For example, perhaps the answer for you is to extend the radios plugin or write a new custom plugin based on the existing radios plugin. Perhaps the customization would be to accept not only simple arrays but arrays whose elements could also be arrays. This way, element that are themselves arrays could then be processed by whatever means your custom formatting required. You may protest that this means that the application designer must now know how the designer will in fact use the data and to some extent, I would be forced to agree. For myself, that is not an issue, but the point remains: custom functionality implies custom code and custom code is the province of the programming team.

There are good reasons to try to keep that attitude when working with Smarty. I would rather have programmers write the custom plugin once and have the designers use that plugin instead of having the designers litter the templates with custom Smarty code whenever they needed some specialized functionality. What happens if you want to change or extend the functionality? One place or every template that happens to use it? In a way, having the designers use Smarty to build custom features is the hack. This is especially true since one of the important considerations to use Smarty in the first place is to remove these types of issues from the template design.

In your case, I suspect that either a clever designer or an interested programmer decided to use the plugins the way you described. Its a cool idea, but is it the best solution? For one thing, it relies on a feature that isn't even supported by Smarty. For another, it means that your template designers are really doing funky things with the data structures and must resort to some of the less favourable mechanics of Smarty (like capture). The whole point of the html_* plugins is that they are supposed to make less work for the designer.

Lets look at another idea, this one often shunned, though very powerful. It is possible to pass objects to Smarty. These objects can themselves expose methods which the template could call. In your case, you can have a method that allows you to append output results to an internal structure on the object. Another method can return an array compatible with html_radios but that also includes the pre-generated output. In this case the designer has more flexibility while the actual (escoteric) mechanics of building the arrays is left to the programmers to deal with.

I hope I don't sound fractuous--but I see a distinct difference between need and desire here: especially since even aside from the previous solutions and the ones I mention in passing in this post, there are also others. I'm not sure if Smarty is really a framework (though in ways it looks like one) or if it is a tool or toolkit. Certainly it depends on how you use it but I favour something that is as simple (and fast) as possible yet easily configurable to custom solutions. On those counts, I think Smarty does a remarkable job.

Phew. That was way longer than I intended! Have Fun and Good Luck!

[mohrt]

boots, we're going to have to ask the phpBB guys to make a way to break a post into chapters just for you.

Monte

[volkris]

The thing is, I really don't see this as a case of "manipulating and rearranging data structures." While yes, an array is more complex a datastructure than a regular variable is, there is still a light year between an array and a linked list, queue, etc. I've said it above, but an array used as I use it is nothing more than a pipe between different template functions. An array is just a way to reference a collection of variables, providing a convenient way to pass that collection to a function.

And yes, the blurring of the seperation that you're forced to admit to bugs me. More importantly it actually poses a real problem for this project. The guy who is writing the majority of the php may be out of touch with the rest for weeks at times, and so those making real changes to the website need to be able to do it without asking for alterations in the form of the data being provided to Smarty. We can assume that he will provide Smarty with all of the raw data needed for displaying, but after that the template is on its own. Such is life in the real world.

As for actual use of the html_ methods, they did exactly what I needed them to do. I had lists to put into html structures and the html_ methods did it perfectly. They also did it incredibly easily using arrays: just pipe from one to another. Modularity is really great, with its code reuse and usability, but the lack of basic array support in Smarty seriously impeeds the ability to pass data to modules, harming their usefulness.

The options you present are all more complicated and more involved than simply piping from one to the other. It's a matter of the lacking in basic infrastructure requiring more work and drawing harder to follow code from the template developer... not a good thing.

[boots]