Template Engine

[WillyC]

pw.shorter way

<?=$page->titsle?>

[Joss]

pw.shorter way

<?=$page->titsle?>

I've been caught out with that - on a shared server where they did not have the php short code thingy switched on, so did not recognise the opening <?

Should not be much of a problem in most hosts, but always worth checking, maybe.

[MatthewSchenker]

Hey Everyone,

I was weaned off short tags some time ago after working with some developers who threaten to blacklist you if you use them.

So maybe they aren't as bad as I have been led to believe?

Thanks,

Matthew

[SiNNuT]

Hey Everyone,

I was weaned off short tags some time ago after working with some developers who threaten to blacklist you if you use them.

So maybe they aren't as bad as I have been led to believe?

Thanks,

Matthew

There's the short open tag and the short echo tag. In php5.4 the short echo is always available but not the short open tag. Some more info here with a comment from a php dev member.

I quite like my short echo's in templates and don't consider them bad.

[ryan]

I was weaned off short tags some time ago after working with some developers who threaten to blacklist you if you use them.

So maybe they aren't as bad as I have been led to believe?

Personally, I prefer not to use the long version tags because it's just more verbose and hard to read. I only use them if I'm developing something that has got to be portable to systems I don't know of. That's why you see me using the long version tags in PW's code and profiles. But if I'm developing something for a client or myself, where I have some control over the server, I stick to the short echo tags when possible. I was very happy when I heard the PHP 5.4 announcement was making the short echo tag standard (that's the main one I care about). 

[MatthewSchenker]

Greetings everyone,

Sounds like the short tag/short echo tag did create a bit of temporary confusion -- easily cleared up.

Personally, I wish all short tags were acceptable. It seems so much more linear to use <? ... ?> for code. But obviously we had to stop using this for other reasons.

Regarding short echo tags: I just got used to doing <?php echo for everything. But discussions like this are a good way to help move away from that!

Thanks again,

Matthew

[Joss]

Everytime I see <? rather than <?php I think...

PHP3!!!

Much to my amusement, I noticed that an old acquaintance of mine that does a little bit of really, really bad website design and hosts on his own server, is still doing everything in PhP3.

But then, he is also still doing everything a fixed 640 width and with very little CSS. I think he sees "styles" as something the gaming kids play with while serious people use <font>.

He has eventually stopped wearing cords, however.

[diogo]

I wasn't yet born to webdesign when your friend froze in time....

[Joss]

I wasn't yet born to webdesign when your friend froze in time....

Really?

At that time I was already on to my second career!

[teppo]

In my humble opinion what's most notable about short echo tag is that it's inconsistent with everything else in PHP. Since this is another age-old "my programming style is better than yours" discussion, I'm trying not to go too deep here, just saying that I'd very much prefer one clean syntax over multiple variations. And yes, I know short echo tag is just one little quirk in the whole PHP soup, but still

The RFC for short tags introduced two basic code samples:

This is a home page for <i><?php echo $user; ?></i>.
Last visited at <?php echo $lastvisit; ?>.

.. and ..

This is a home page for <i><?= $user ?></i>.
Last visited at <?= $lastvisit ?>.

.. summed up with rather one-sided "The second form looks much nicer and cleaner". Personally, I have to disagree with that:

• First example makes it clear what's happening, even if you're not familiar with PHP - as long as you're even remotely familiar with pretty much any other programming / scripting language; you're using PHP to echo (output) a variable. Plain and simple. One could insist that "print" would be even more universal, though, but in PHP it suffers from minor performance overhead so I'll let this one slide.
• Second one does exactly the same thing, but with obscure syntax (again in my opinion) that's unique to even PHP itself.

Don't get me wrong - I do love PHP. It's just that I also love everything that's consistent and would prefer if devs took it that way instead of nurturing so many different syntax choices, naming conventions etc.

[Joss]

Quick, rewrite PW in PERL!

[MatthewSchenker]

Greetings,

Interesting discussion...

Thanks Teppo for the link to the RFC. Seems this is not settled, which I suppose is good.

So it seems we can and perhaps should continue using full echo syntax.

I kind of feel like the main character in "Fiddler on the Roof," when he's considering different options and says, "On one hand... But on the other hand... But on the other other hand..."

Thanks,

Matthew

[Soma]

Just wanted to add to this discussion that one of the clear benefits of using templating engines is being able to share templates and partials between different programming languages, and thus between client side and server side aspects of your site. This is very handy when building web apps or heavily ajax-ified sites.

I get the idea, but have hard time to see a good use case or the clear benefits. I think I get the point but hardly felt need to share templates between languages. Care to elaborate a little more with some real examples or resources where this comes into play? 

[teppo]

Quick, rewrite PW in PERL!

Sorry for taking this even more off-topic, but my vote goes to APL.

[Joss]

Tandy Basic?

(Sorry, that is probably far too "uk" and, um, old)

[DaveP]

Tandy Basic?

(Sorry, that is probably far too "uk" and, um, old)

I believe it would be Radio Shack in the US.

[MatthewSchenker]

Greetings,

Yes -- it was Tandy sold by Radio Shack!

I remember the TRS-80 fondly: http://processwire.com/talk/topic/2254-syntax-and-coders-with-history/?p=21050

Thanks,

Matthew

[DaveP]

Great value, too. TRS-80 Model III for just $2295, and that's with 2 x 184k 5 1/4 inch floppy drives! http://archive.org/stream/radio-shack-catalog-rsc-09-computer-catalog-1983/radio_shack_catalog_rsc-09_computer_catalog.1983#page/n21/mode/2up

[Joss]

I remember one of our runners getting one for his birthday and turning up with it at the studios. He was so pleased with him self.

At the time, my brother was working for the great Ed Ross (designer of the Quantum statistical engine) just down the road and they had bought a brand new Prime mainframe.  (I think we used it to play a very early version of Zork - well, had to use it for SOMETHING important!)

So I looked at this rather dreadful wooden box with a few wires coming out of it, then I looked at the mainframe with its room full of white terminals, humming air conditioning and huge, floor standing drives....

Little did I realise that the tatty piece of nonsense was destined to be far more influential and important that that hugely expensive, room full of tape drives!

[lucas]

I'd love to have the option to use a template engine instead of plain PHP in ProcessWire. I'd even pay for such alternative... just saying.

And I must say Twig looks *very* interesting!

[Wanze]

There is a module for Twig:

http://modules.processwire.com/modules/template-twig/

[ryan]

Twig is a nice template engine. I'd like to explore the possibilities of expanding upon what porl started with that module sometime. Though ProcessWire will always be based on a PHP API, but I'd like us to have a simple integration method for supporting other template engines for the people that want them. 

[MatthewSchenker]

Greetings,

I have played with various template engines, and I agree that Twig is better than others.  I've also tried Smarty.  There was a time when I believed I had to do one of these because "there are people who don't want to use PHP."

But these days, I don't believe this any more.  Instead, I believe that using a CMS like ProcessWire makes it possible for "regular" people to deal with PHP.

One of my main attractions to ProcessWire is that there is an attitude that template engines are not necessary.  Maybe it's just me, but no matter how good a template engine is, it's just another thing to learn.  And because there are several template engines, choosing one runs you the risk of creating code that is not as "universal" as PHP.

I understand that in some agencies there are designers who don't want to deal with PHP.  But the best of all worlds -- it seems to me -- is to use a CMF like ProcessWire (or a framework like Laravel and CodeIgniter), whose syntax is clean and expressive, thereby making a template engine unnecessary.

Thanks,

Matthew

[Natetronn]

Let's not forget the original topic of this post way back when I posted it which was finding a way to make using PW themes easier than WP.

The requirement is that it must be as easy (or easier) than WordPress, both to install and use

With WP most people who don't know how to use a lot of PHP end up buying a theme as is or maybe buying a theme and re-skinning it directly (via css etc.) or even using a child theme. And we all know there are a bazzillion themes out there to choose from. Allot of them with built in admin panels for changing almost everything in a design from colors to fonts to logos etc. Then little by little when they out grow re-skinning and feel more comfortable with things they start playing with PHP and WP's "loop" among other things.

Bringing up template engines was only one idea to help make things easier for people though, I'm sure there are many other ideas as well. With that said, it's probably a much bigger issue than just using a template engine or not.

PW, as it sits now anyway, isn't really setup for themes as much as it is for building sites from scratch. This is similar to other systems, like EE for example, as you can't install themes over themes per se. I think that's the case with PW as well though, I could be wrong so, please correct me if I am.

 

The flexibility, power and freedom CMS like this provide takes work to use & to learn and often times when you are just starting out its just easier to, well, not work/learn.

Anyway, maybe that was why the post was started in the first place, I don't know. For me, offering a template engine is kind of a mid ground in a sense, as it allows people with less php experience to "feel" more comfortable. I do get the arguments about having to learn one thing so, might as well learn PHP from the start, however, that doesn't address the issue at hand (or at least the original topic from the quote.)

By the way, there are also other reasons which no one has mentioned which make using a template engine a possible good option like separation between logic and view (or what ever it's called.) Allot of other languages, frameworks actually, offer this pretty much by default (although by choice.) Not saying PW needs to do that rather, I'm just saying.

Ultimately, I guess we never really answered the question from the quote above and I'm curious (as I don't know myself) how to make working with and installing PW themes as easy (easier) than WP?

(and let's not forget about one click upgrades for both core and modules!)

[apeisa]

Nate, I don't see how front-end themes could come from just adding template engine. PW is much more flexible in it's data modelling than WP and markup generation (just like EE is) and that is the reason there cannot be traditional "themes" that can be just switched.

Answer to that need in ProcessWire are site profiles. There ain't many yet, but as PW grows in popularity, I am sure we will see plenty of different site profiles that people can use as a starting points. Install "basic portfolio profile" and just tweak few settings in admin to manipulate the looks. In that scenario I think multiple template engines just confuse: "This product catalog profile is build using TWIG templating engine" or "This profile uses SMARTY as template engine". Instead of all them using just PW API and PHP.

I am not sure if it is a good or bad thing to allow new template engines added easily. Probably good, though.