Smarty

[andre]

[wintermute]

Hi messju,

[gjmacd]

Hi There...

We use Smarty in our product, we love it and its worked out great.

Moving from XSLT over to Smarty has been the right choice for both our business and our customers. Our use of Smarty is signifigant in our technology and our customers seem to have gotten most of what we're trying to do.

Lately, we have found that we've been seeing "issues" with the amount of native Smarty code in templates. This is something that we thought would be no big deal (and expected these Web Designers to learn Smarty), but since our customer base is pretty much "non-Coder's", the issue tends to be more of "whats this stuff, and can I get rid of it...".

As you can see, we do a lot of hand holding.

What we've come to as a solution/suggestion is to get even more "HTML" like with the templates. We'd really love to see it where Smarty becomes completely transparent in the template and truley is "non-intrusive" when your using a tool like Dreamweaver -- which is what our customer base uses.

Here are the suggestions, and we realize some of these are drastic, but we do think they would GREATLY benefit the Smarty community as a whole.

Remember, our main goal is to keep our customer base doing HTML and designing. Learning Smarty is possible, but its clearly not the top-priority.

.... One suggestion is to keep the syntax embedded inside of the HTML tags themselves, for example, instead of:

<table>
{section name=i loop=$items}
<tr><td><span>{$items[i].id}</span></tr>
{/section}
</table>

Notice that this section loop, if you look at this in Dreamweaver, you'd see a bunch of stuff in design-mode that you'd not want to see. Further more, if the Web Designer isn't careful, it could spell disaster for the template...

What we suggest is simple:

You'd tuck that section loop inside of the HTML entity, and when displaying data, make sure you use an HTML entity to as such:

<table Smarty:section="i,$items">
<tr><td><span><!--{ $items[i].id } --></span></td></tr>
</table>

This does a couple things.

#1. It makes sure that the template will display in an editor.
#2. It reduces the syntax down to a simple html attribute

There many other variations of this method, but the point we're trying to make is to keep things inside of HTML as much as possible.

Our other suggestion is to ensure that {literal} simply goes away.

{literal} causes a HUGE amount of issues when someone try's to author new templates and forgets that they need to encapsulate something in a literal. How about simply knowing the tag's to ignore and not compiling / parsing the code between the tags.?

Hopefully, we're not dredging up old dirt. We're only trying to suggest what would make a very good template engine simply the best template engine.

We believe changes like this can only benefit and not detract from the technology... Whether it will or can be done is something that people here have to answer...

[mohrt]

Why not set your delimiters to <!--{ }--> ? I'm not sure if the span tags are necessary, but they can be included as well.

[gjmacd]

changing the delimeters to <!--{ }--> would be half the battle, but I think if you read my previous post, you'll realize that we're really looking for a complete solution around HTML...

[mohrt]

What's the other half? This takes care of html encapsulation and the literal tag issue (don't need it)

[boots]

gjmacd:

I think I see what you are getting at but I think it is more complicated than your example seems to suggest. Sure, table looping is a simple example but even there, you'd have to come up with a scheme that differentiated handling things like vertical/horizontal looping, handling headers, etc. It also doesn't address things for which there is no HTML equivelent, for example looped divs/spans, etc. There are other issues: you use Dreamweaver (and I understand that there are plugins for Dreamweaver that "enable" Smarty) but what of other users? Is it justifiable adding non-compliant attributes to HTML/XHTML (with non-compliant syntax, no less)? Is there any less that the user needs to be aware of in this circumstance? I say no: it is only packaged differently and its main merit seems to be that it will integrate better with your user's toolchain (which I do admit is a strong point).

Probably the least desirable thing is that this removes the general-purposeness (excuse me for making up words) that Smarty has: HTML is only one type of output that Smarty is used to generate. IMHO, using HTML to represent imperative coding paradigms/structures is even less appealing than using XSLT's declarative design (which I am no fan of either).

Perhaps there are things you can do to deal with your issues; for example, if you have a specific vertical application and can specify the various details of how you would like it to work then it ought be possible to write a pre-filter that takes your code style and transforms it to Smarty compliant code. In your example, the pre-filter would detect the table attributes and re-write them as a standard Smarty loop. The user would be unaware of this and your coders (particularly those that are writing the pre-filter) could rely on the features that Smarty brings to bear.

Another thing to consider is that if there is a lot of generic Smarty code that is repeatedly finding its way into templates, perhaps you can benefit from repacking that functionality into plugins. That ought to make templates less intimidating and while making added functionality easier to identify and understand. In other words, perhaps there is a custom set of tools you can provide that will reduce the types of coding stresses you are observing.

I guess my basic premise is that while I think your idea has merit, I think it is more suitable as an addon or an extra layer that is built upon Smarty than a base feature.

Just my 2c.

[gjmacd]

Remembering that Smarty is in interim "template" before it hits the browser is important to my case here. I don't want people to think that I'm trying to create a new HTML standard -- what we're looking for is platform which designers (non-coders) can live happily, and developers (coders) can hack away.

A common ground.

First off, I'll address the XHTML compliance issue. I really feel that we're not talking about the end-point here. When we discuss Smarty, we're talking about "design time" and what matters most at design-tiem is that the design-time elements make it easier to design. XHTML (in my opinion) is not important until the final result hits the browser -- its not a design time issue. I think people can live with non-Compliance (as we do now) using Smarty in something like Dreamweaver. To me, this is not really an issue if your end result is compliant once it hits the browser...

As far as my example being simplistic. I think it is. However, the statement [to paraphrase] "what about more complex things which there are no HTML equivalent". Thats a great question.

I certainly think that if you want to code Smarty the way it is now, you should be able too -- we should never remove its general purpose nature of Smarty, but we should not ignore Smarty's natural ability to be an HTML templating platform.

Wouldn't it be great if you could have templates that actually were HTML compliant in that when someone loaded up DW or GoLive, they held the design and presented well in the WYSIWYG editor?

Right now, (INMHO) there is way too much "noise" in these templates.
Yes, plug-ins help. And we have moved a lot of general purpose Smarty code to plug-ins, but again, when your a designer and you see:

{MyPlug value=foo param=1}

Its not optimal. In this case, hiding that plug-in with:

<!-- {MyPlug value=foo param=1}-->

Will probably do the job...

Your point about DIV and SPANS are pretty interesting. I would think that :

<div Smarty:section="i,$items">

</div>

Would translate...

as would :

<span Smarty:section="i,$items"/>

The question is "how far do you go?". How far along the path do we take this?

There are things that I can see would present issues. But the bottom line is that with a little work, we could get about 90% of the WYSIWYG issues knocked off.

I think most people will agree that Smarty inside of something like Dreamweaver is pretty much "broken". When your sitting down in front of that screen with a Web Designer (even with that DW Extension), they look at the screen and wonder what the hell happened to their layout. Worse, they see the braces and try to work in WYSIWYG and get all frustrated at what they can move, change or edit.

Its not completely a disaster, but its certainly not the optimal situation.

Sure, not everything will translate. But as I like to say, "make the hard things possible and keep the simple things easy". This is a case where if the parser were to "add" the ability to keep the Smarty syntax inside of the HTML, it would go a long, long way totwards being adopted more in the commercial world instead of people going to ColdFusion or Miva (which I think are quasi-competitors).

I know this is a somewhat taboo subject, but I feel at this point with my user base, which is growing (over 50+ customers now), its only going to get to be a bigger issue.

We've looked at other template engines. Flexy, which does a lot of what I'm talking about is an interesting thing. The reason why we are sticking with Smarty is that we love the support and really feel that its the most stable and well supported thing out there.

Now if we can get just a couple things crowbarred in...

[boots]

Okay, I'm willing to bite because I think you make some good points when it comes to integration.

For the sake of discussion, let's call your idea annotated tags. Before suggesting how this might be implemented, how about we draw from the experience of your user base -- can you come up with the top 5 or 10 things that would Make-A-Difference and itemize those in a concrete manner? [disclosure: I don't use Dreamweaver or other wysiwyg design tools so my experience there isn't relevant]. You seem to have got the ball rolling already--a collected list and some quick notes should fill it out.

I do believe that the easiest path to integrating this idea into Smarty would be to apply a pre-filter that transforms the annotated tags into straight HTML with standard Smarty markup. Some custom plugins might come into play, but that depends on the items you come up with in your list. This really is Yet-Another-Template-Layer which I'm sure will annoy some folks but if nothing else, it ought be readily doable.

That said, I'm not sure I fully buy into the premise that this will help in the long-run: hopefully a more tangible set of requirements will help convince me (and others). If your list is reasonable enough, I'd be willing to help develop this further.

One thing that is turning over in my head is that the question as to how long HTML will continue to be an important development platform; I'm sure it will continue to be an important target language for rendering but otherwise I think all bets are off. Meaning that shoehorning too much into HTML may not be wise in the long run.

EDIT: Hmm. The more I think about, the more I wonder if this is really going to change anything other than syntax. Simply hiding things by using something like <!--{ and }--> as delimiters seems reasonable enough to me.

[gjmacd]

Here's a short list. I'm a big believer in keeping things simple.

How about three to start with!

As far as your comments about HTML going away, well, I hardly think that will happen in our lifetime. Although, my Red Sox won the world series, therefore, hell does sometimes freeze over...



1. Encapsulate looping / iteration inside HTML namespace elements.

Since 90% of the logic of a template in my experience is displaying tabulated data and forms, this makes sense.

With a Smarty "{section}" being the norm, this syntax clearly breaks the flow of a design layout in a WYSIWYG tool.

I'm not going to suggest syntax here. But I would suggest making sure that the syntax in question keeps in conformance with an HTML namespace.

Per the earlier discussions.

<table Smarty:foreach="i, $items">
</table>

The two parameters are the iterator and the array. Of course, there are more to be used, but you get the idea.

This is going to be the most complicated and political part of the process, but I think its the most important. This will clearly allow for the design to stay within the design and not allow Smarty to interrupt the process of the layout in an editor.


2. Removal or hiding of {literal} elements around <SCRIPT>, <LINK>, etc.

This is a big frustration for designers. They code up a page with outputed script from something like ImageReady -- which does all that rollover and CSS mess, they put it into a template, and blammo, nothing works at runtime and they get a big compliler error.

Thus, they call our 800 number and we say "did you read the FAQ?". Of course, nobody does.

But if you think of this logically, this IS HUGE. Most people generate an HTML file from a tool like ImageReady, Dreamweaver or GoLive. The output is usually a mixure of script, styles and various other "setup" for the page. Smarty clearly falls down in this area simply because someone who has been is used to layout in HTML is not used to knowing the nuances of Smarty integration.

3. WYSIWYG Friendly delimeter replacements

This is obvious, but it would be nice to have both { } and <!--{} -->
work as a default. Thus, when coding in DW, your "smary logic" doesn't bust the design. People have mentioned using a prefilter and a delim, which is fine, but this should be pretty much a default in the product itself as its too much to expect a laymen / novice to understand that type of thing. I should add that although this method works for most inline smarty syntax, it does not bode well for making your pages seem "clean". Having lots of comment systax in pages looks a little odd. Also, how would one do a foreach using this method?

Somehow, the following doesn't seem like it will work...

<table <!-- { } --> >
</table>



This is the short list. Of course there could be more, but thats not the point.