do Smarty and PHP go hand in hand.....and are these not two separate things...please tell me whats the main concept behind the separation of the application (the codings) and the presentation (the looks which includes the HTML tags) parts in Smarty
Smarty and PHP go hand in hand in the sense that Smarty is a template engine for PHP - you will need to have PHP installed before you can use Smarty. With Smarty you can keep the HTML separate from the PHP. This is good for multiple purposes, such as not having to touch the .php files when you only need to edit the layout of a page.
Smarty is designed so that designers without PHP knowledge could easily learn it and create the UI. It's designed to be much cleaner than PHP and have a simpler learning curve.
Smarty is looking pretty dated at this point... as in most of those in the PHP community are stuck with it as a legacy app as opposed to starting to use it now. It was an excellent option 4-5+ years ago - the last time I used it regularly was 2006/7 - but at this point the alternative syntax is just a pain.
If you can't use straight PHP, you might check out Savant.
A good thing to consider instead of smarty is
echo "";
:)
Plus most frameworks have a layout/display system that is very similar to templating but without the unnecessary bloat.
Related
Please explain what a template engine is, and what it is used for. What are the paragraphs below trying to say? I don't follow the author's explanation.
Although CodeIgniter does come with a simple template parser that can
be optionally used, it does not force you to use one. Template engines
simply can not match the performance of native PHP, and the syntax
that must be learned to use a template engine is usually only
marginally easier than learning the basics of PHP. Consider this block
of PHP code:
<ul>
<?php foreach ($addressbook as $name):?>
<li><?=$name?></li>
<?php endforeach; ?>
</ul>
Contrast this with the pseudo-code used by a template engine:
<ul>
{foreach from=$addressbook item="name"}
<li>{$name}</li>
{/foreach}
</ul>
Yes, the template engine example is a bit cleaner, but it comes at the
price of performance, as the pseudo-code must be converted back into
PHP to run. Since one of our goals is maximum performance, we opted to
not require the use of a template engine.
A template engine is simply a way to embed your back-end code into your html. This is more common in languages like Python and Ruby than PHP since PHP already supports embedding within html code.
That specific templating engine may be easier for those coming from other back-end languages, particularly Python or Ruby since Django and Rails have very similar-looking syntax for templates.
While not necessarily a "template engine", I typically organize my Codeigniter projects where I have a template.php view that contains the skeleton layout and the content of each page of the site/application is a separate view that is loaded within the template.php file. This way I am not rewriting code on each page.
Template engines are all about personal preference--they aren't needed, but some people feel more comfortable using them if that's what they are used to. And people are more effective the less they have to think about their workflow!
In CodeIgniter Userguide describe that CodeIgniter does come with a simple template parser that can be optionally used, it does not force you to use one.
But if u want to use template, I suggest to use this library that it is very simple.
http://williamsconcepts.com/ci/codeigniter/libraries/template/reference.html
I am currently developing a PHP site which I plan to use with Mustache PHP so that I can use the same mustache template files with my PHP rendering as well as with my javascript (ajax driven) page updates. After searching around, I was not able to find a handlebars.js equivalent library for PHP, although I would prefer to use handlebars for everything.
I am in the process of deciding whether to use Ember.js or Backbone.js. I know that Ember uses handlebars and that handlebars uses syntax and features not present in mustache.js, which it is based on. I also understand that handlebars.js works with mustache templates just fine.
I am leaning towards Ember and am willing to fork and update Mustache PHP to work with Handlebars.js if necessary.
But first of all, will Ember.js work nicely with straight mustache templates? Or does the proper leveraging of Ember also imply the use of template features that only handlebars supports?
If I do have to fork the PHP library, what are the main handlebars features I will be itching to add in first?
Thanks in advance, this will really help me decide if it is worth it for me to use Ember.js.
Handlebar.js adds some "helpers" on the Mustache(.php/.js) syntax... But these are completely useless as Mustache does this already very well:
{{#each xyz}}...{{/each}} is the same as {{#xyz}}...{{/xyz}} in Mustache.
{{#if xyz}}...{{/if}} is the same as {{#xyz}}...{{/xyz}} in Mustache.
{{#with xyz}}...{{/with}} is the same as {{#xyz}}...{{/xyz}} in Mustache.
In contrast:
{{#unless xyz}}...{{/unless}} is the same as {{^xyz}}...{{/xyz}} in Mustache.
Ember.js looks very much like handlebar.js, while Backbone.js seems to add a lot of logic to the logic-agnostic Mustache-Kind-of-rendering some output.
I'm using Mustache(php) on some small and large sites. Ajax calls result in Mustache filling out a peice of html and jQuery replaces some dom elements with the result. It's working like a charm.
To me: Don't add logic to Mustache, just remove the logic from Handlebar.js (I guess it will work without those "helpers" as well.)
I didn't need to use Ember but did notice that not long after I posted this question, someone else began the project of Handlebars parsing within PHP and this library is another approach. These libraries were the solution I was looking for since there were so many potential complications with treating handlebars templates using only a mustache renderer.
I know things like these have been asked and answered several times before, is it just that I can't grasp the idea easily or too hard to accept that things are really like this and that.
I know that HTML is used for Front-End where the tedious work is done in the Client, and PHP is working behind the scenes (Server-Side). With so many regulations, instruction, standards, so on and so forth.. I believed I have already confused myself with these stuffs, making things (new and old) hard for me to chew and understand especially when it comes to their best uses...
Anyway, I have created a web application based on the concept of MVC tho I didn't used the strong fundamentals of the topic nor a framework, I separated the Logic, Rules and Design concerns by my own.
Unfortunately, I wound up with some issues similar to which is the right way to do the things, how this should be implemented, etc...
I end up needing to template the HTML, however, since I've used HTML as HTML itself, I end up updating/editing each and every affected file (for. eg. a web page header), unlike when I used PHP before, literally a file with a .php extension, where I can fully utilize templating, however, i read somewhere that it is not a good practice because it breaks the HTML.. so which one should I follow and how can I solve my problem, should I move to .php and then create a template page, or is there a way I could do such with HTML? if there is any, how can it be done?
Please for the meantime, don't point me to frameworks available, I want to understand basic things first before studying frameworks...
Anyone, please...
Edit...
so this is just fine and that it doesn't have any drawbacks...
main.php
<?php php stuffs ?>
<html>
<body>
HTML stuffs and some <?php php stuffs ?>
</body>
</html>
HTML has no templating capability.
It has frames and iframes, but they come with significant drawbacks and only provide include functionality.
You should use a proper templating language. This can run on the client, server or build system.
I'd recommend against running it on the client. It adds an unnecessary dependency that your visitors (including search engine indexers) have to fulfil.
PHP will do the job (it straddles the border of being a programming language and a templating language). My personal preference is for Template-Toolkit.
TT can run in your build system via the ttree utility, or you can run it on your server. There is a tutorial covering how to build websites using it.
If, and when, you move to building websites with more demanding server side requirements, then you can continue to use TT as it is supported but most of the web frameworks in Perl land (e.g. the dancer module for TT and the catalyst module for TT. Note that those links go to the hardcode documentation for the modules, and if you plan to use one of the frameworks you should start with a higher level tutorial)
HTML is a markup language - in other words it can mark up text to display to the user.
It cannot do any of the dynamic type functions you might need in a web application - like updating the date, for example.
So it is best to think of HTML documents, just like you might think of a Word document, a load of text that is displayed to the user.
As soon as you want to start using templates to display dynamic information (stuff from a database, maybe), you're going to need a scripting language. PHP is good for this.
I've had good experience with Smarty - a php templating engine.
On a side note, learning a framework can be a really useful part of the learning the basics. Most frameworks force you to do things in a good way, and sometimes the things they make you write in your code may seem a bit strange or illogical, suddenly one day the penny will drop and you'll realise why what you've been forced to do is sound from an engineering point of view.
You can look # javascript templating. I suggest you to give a try to http://mustache.github.com/
Modest is a template system that's supposed to look and feel like HTML.
The most common way to do HTML templating with PHP, is to use one of these popular templating engines :
Smarty
Twig
Latte
Mustache
Alternatively, you can just put placeholders in your HTML that look something like <% variablename %>. Just load your HTML, do a regex do find all placeholders and replace them with the corresponding variables.
Alternatively, you can load your HTML, parse it as a DOM document and then modify your DOM. I created the library DOM Query to be able to do this with a jQuery-like syntax, but you could use vanilla PHP or one of several other libraries as well.
Alternatively, you can do some HTML templating in frontend with JavaScript. If you want to do HTML templating both on frontend and backend, you might want to consider using Mustache, because Mustache templates can be used both in frontend (with JavaScript) and in backend (with PHP).
I've been on a project with a buddy who is leading us with Middleman. We are coding in HAML and SASS and he's obviously a Ruby Dev. I'd like to know if there's ANY type of equivalent for PHP? I'm going to eventually lead a team and I'm much more comfortable with PHP than Ruby.
I'd like to have a layout file (like Zend's layout file)
I'd like to...at one command, convert all of the source files from PHP to static HTML and place those static files in a 'build' folder so we can hand it over to the client.
Anyone know of some cool things out there to make this happen? Thanks a bunch!
A project I work on, www.findbigmail.com, was written completely in PHP to start with and then I did some Ruby/Rails work for a different project, and coming back to PHP was a grind. After using HAML, SCSS and other wonderful things like CSS and JS minify, oh and Compass to build sprites, it was painful to go back to PHP and work again in PHP files with embedded HTML etc.
So, driven by pure slothfulness, I looked around and found MiddleManApp (MM) - after a couple of side trips along the way.
Now we have a very strong separation between what is now a mostly static html site built by MM, with some PHP files that are POSTed to and then redirect back to html pages. Where we need more dynamic behaviour, we've added javascript to the pages and have them call PHP API wrappers around our pre-existing code.
Our site performance has jumped hugely (doh, now its all static html), and its poised to take another jump when the next MiddleMan version comes out with its improved cache-busting abilities inherited from the Rails 3.1 asset pipeline. E.g. we'll be able to reference main.css in our source scripts (which itself is made up of sub-scss files like _index.scss, _pricing.scss) and it will be built with references to main-2348jlk23489kdj.css -- allowing us to set the server to cache for a year and/or deploy many more files to CDN.
Our engineering performance is way up too. We're no longer reluctant to touch UI code for fear of introducing a syntax error into the PHP code. And no more mismatched HTML tags to cause grief. The other PHP developer wasn't familiar with the Ruby/Rails derived toolchain, but has quickly become proficient (though he is a rockstar developer, so that's not too surprising!)
Coming soon is i18n support. Most of that is in MM already and hopefully Javascript support
real-soon-now.
We also explored generating pages from HAML with PHP added to them. We decided it was probably quite simple - e.g. add a ":php" tag to the HAML pipeline and then use .php partials as needed. But, we found that between Javascript and wrapping the existing PHP code as an "engine API", we were able to keep the codebases neatly separated -- which we found we prefer overall.
I hope this helps! Happy to explain more.
There is one for PHP called Piecrust.
I ended up choosing Middleman for the bundled coffeescript, sass, etc., but Piecrust is well done.
http://bolt80.com/piecrust/
PHP can render static HTML from PHP code quite easily:
Easiest way to convert a PHP page to static HTML page
Generate HTML Static Pages from Dynamic Php Pages
PHP - How to programmatically bake out static HTML file?
You could wire up something with existing template systems like Twig or use PHP Markdown to more or less mimic what Middleman is doing and create static HTML pages from your source files.
EDIT: As Hari K T mentioned above, http://www.phrozn.info/en/ does exactly this.
I've been looking for some guidelines on how to layout PHP code. I've found some good references, such as the following:
http://www.dagbladet.no/development/phpcodingstandard/
and this question on SO.
However, none of that quite gets to what I'm specifically wondering about, which is the integration of HTML and PHP. For example:
Is it OK to have a PHP file that starts out with HTML tags and only has PHP inserted where needed? Or should you just have one section of PHP code that contains everything?
If you have a chunk of PHP code in the middle of which is a set of echo's that just output a fixed bit of HTML, is it better to break out of PHP and just put in the HTML directly?
Should functions all be defined in dedicated PHP files, or is it OK to define a bunch of functions at the top of a file and call them later on in that same file?
There are probably other questions I'd like to ask, but really I'm looking for someone to point me at some kind of resource online that offers guidance on the general idea of how HTML and PHP should be combined together.
Combining programming code and output data (including HTML) is IMHO a very bad idea. Most of the PHP gurus I know use a template engine such as Smarty to help keep the two things separate.
There's really not a single, common standard for these things. Most languages are more restrictive than PHP in this sense.
In the later years, a lot of so-called frameworks have emerged, and amongst other things they define a set of rules for everything from naming over where to place files and to which style your code should follow. There are several frameworks around, so you can't really pick one and call it the standard. However, most frameworks have a subset of commonality. For example, most follows some variant of the PEAR Coding Standards.
I usually try and follow the standards that are set by the language's core libraries.... oh wait.
Seriously through - you should try and follow the MVC pattern in any web application as it is pretty much standard practice regardless of language. In PHP this can be achieved in a quick-and-dirty way by treating index.php as your controller and separating data logic and presentation by file. This small step will at least let you move your code to a full featured framework when and if you choose.
Use a template engine when you can. If you haven't learned one, or don't want the overhead (which is minimal), use practices that cause you to have quick-and-dirty templating:
Functions that do not display anything have no place in a file that does display something.
Print variables, not HTML. Whenever outputting HTML, break out of the PHP and write HTML with print statements to handle any small details that are needed (actions for forms, IDs for controls, etc.).
Remember, when you include a file that breaks out of the PHP to print content, that will be treated the same as if you do it in the main file. So you can create simple templates that just included PHP files, and those files will print variables in the right places. Your index.php (or whatever) does all the real work, but all the display is done by the secondary "template".
Many PHP tutorials intermix logic and display code. It took me years to break the bad habits that encouraged in me. In my experience you can't separate things too much in PHP, and entropy will pull you towards intermixed code if you don't fight it.
Coding standards should be more than how to layout your syntax, but sadly that's what they tend to be in PHP.
FWIW, phc will pretty print your code in the Zend style.