what are the benefits of using a template engine - phalcon

I do not understand why a developer would use Phalcon's Volt template engine.
In the end, after the compilation, the same PHP files are produced, that I would have to write manually in the first place. To me, it looks only to be detrimental to the performance.
Is the answer "so you could pass .volt files to a front-end guy"?

The answer lies in the development of your application. Why do you use a framework instead of pure PHP? Why bother with object oriented programming when procedural/straight PHP is faster?
There are many reasons of course and it is a long discussion. The summary is ease of use and maintainability.
The same goes with Volt. You can use the volt templates to do what it will take you a lot longer if creating plain phtml files (HTML with PHP tags in there). Examples I can give you are template inheritance, partials, calculations within the template (for/each loops) etc.
As far as performance is concerned, there is always a performance hit when using a template engine. Volt luckily is part of Phalcon so the performance hit is minimal since Phalcon does all the hard work in memory instead of using included files here and there to offer its functionality.
The decision is up to you. Volt, Smarty, Twig and others are there to help with development of your application. Your decision is what makes you use the template engine or not.

This is an old question, but I want add some insights.
You asked why you should use Volt, the Phalcon template engine, but in your explanation you want know, more generically, why you should use a template engine. The short answer to your question is: you must use a template engine to avoid mixing PHP with HTML.
But I want answer to the main question also. Why Volt? Volt overload is minimum compared to every other template engines out there and it's not because is written in C, but because it generates a unique PHP file for your view.
Twig is probably the most complete template engine out there. Twig has many more features compared to Volt, it's more stable and older. Twig, anyway, doesn't generate a unique PHP file, but a bunch of PHP classes with methods that call each others. Doesn't matter if you are using the Twig C Extension, Twig is gonna be slow anyway.
Twig is really really slow when compared to Volt and even to the good old Smarty. So, if you are using Phalcon is probably because you want achieve the best performances, serving a lot of page requests; in this case Volt is your friend.

When history of PHP starts, it was standard, that HTML was generated directly inside PHP scripts. But it happen to generate some problems when it grown to one of most popular ever web programming languages.
To keep people working in huge projects comfortable with their tasks ie. when developing web services, where was an MVC architectural pattern invented. M for Model is used to store data and handle them in a maintainable and repeatable manner. V for View as an part, that is responsible to generate proper output. C for Controller that are responsible for sending commands to models etc., being a core logic of application.
When user send a command to service, Controller is handling it and understanding. Triggering changes on proper Models and maybe forwarding actions to other Controllers as long as View Controller is reached. View controller takes a proper view, injects into it generated data and executes it to create output that is send back to user. If template for view is not yet generates, it triggers template engine to do it.
Proper implementation of full MVC greatly helps both programmers, system architects, front-end devs etc. But when on one side it happen difficult to maintain databases (so ORM were developed), on other side of system it was difficult to maintain views.
One of principles of MVC is that Logic (with huge "L") is only in controllers. So there is no logic in views. Using template engine enforces easiness of achieving that because of poor support of logic by them self. It is not a secret, that programmers are "lazy" - so if they have an occasion to put some more advanced logic into view, they would do it.
I guess that all frontend devs have programming skills. Problem is to make them stay with you. Working on huge project with lots of views (and so hudge templates) with PHP mixed into them will drive them crazy. It is much easier to read code written for template engine.
Idea of template engines is to add one more part to system, that offers possibly simple language allowing to use basic logic like loops and if statements. On one side template engine receives kind of a textual file to transform it into PHP file with mixed into it hyper dose of all important HTML.
If you are alone developer, it is important to nobody that you are using files that mixes PHP with HTML. It looks probably close to this:
<html>
<head>
<title><?=$title?></title>
<? foreach($metas as $meta) { ?>
<meta name="<?=$meta['name']?>" content="<?=$meta['content']?>"/>
<? } ?>
But any frontend developer would rather like to work on file looking this way:
<html>
<head>
<title>{{ title }}</title>
{% for meta in metas %}
<meta name="{{ meta.name }}" content="{{ meta.content }}" />
{% endfor %}
for it higher readability. It happens extremely handy when template includes some kind of javascript inlined. After all, you end up with same file you can create by hand, but this file is generated for you and stored, so it is no more generated as long, as core file is not changed. We are generating our templates during deploy what has 0 hit on performance, especially now, when Volt engine is written in C.
Another handy thing about template engines is that (with some your effort) it is possible to generate templates minified on the fly. You wont ever minify your hand-crafted template, except when planning to commit suicide.
So globally, it is a case of:
so you could pass .volt files to a front-end guy
but it is an effect of working in MVC pattern. And Phalcon is made to fulfill MVC principles. I'm not even trying to guess, how you managed to work with this piece of software for ~2.5 years not using template engine. Maybe you are working alone.

Every person has different taste, but i tell you my vision.
I think volt is useful because:
As all phalcon framework, Volt has excelent performance.
Benefits from template engines (i dont wanna repeat that already other answers says)
Hierarchical rendering: More info -> https://docs.phalconphp.com/en/3.0.2/reference/views.html#hierarchical-rendering
I love the phalcon hierarchical rendering, because is clean, easy, and any person can understand where can find the view of something, ideal for a designer, or other non technical person
And to add value, i modify some phalcon parts to apply that hierarchical rendering using app modules, thats all i need.

Related

Dynamically adding data to divs with SQL?

A little background first, recently began coding and I decided to take the "learn as you go" approach as this is solely a project. I have a pretty good handle of HTML and CSS, I have an understanding of Jquery, and haven't even begun to look at other languages.
So basically I'm making a suedo-e-commerce site, and I'm trying to create a page layout comprising of several divs stacked together (think standard catalog page) Creating the modules and every static with HTML and CSS, but I want to add the content, comprising of a banner and some text blocks, dynamically from a database. Now, I'm pretty sure that I will have to use SQL and reference each entry with the HTML, but I have no idea how to do that or where to even start. So I'm asking if someone could point me in the right direction with some reading material, or some examples would be awesome.
You need to use one of databases (MySQL, MSSQL etc.) to save data. In order to show data from database you need to use one of background/server side programming languages. For start I would suggest that you try with php.
W3schools is good starting point for you.
This is very simplified and I hope not condescending. Consider separating how you collect your data and you present your data (the 'view layer'). SQL will help you pull / organize your data, and you could just string functions to add formatting (e.g. div's) to it, but you are better off investigating templating HTML. What happens when you want to put this data into a ul list or something? You have to re-write your perfectly good SQL. Again, very broadly, pull data (with SQL, PHP, combination), ( or get it from a URL with javascript), into a data structure, then within a loop in your template, add the dives for each element.
Good reading really depends on which platform you'll be developing this in. There are a bazillion alternatives, including many in Javascript, PHP, Ruby, Python, Go, ASP. Since you mention SQL, you must have some data somewhere (rather than a data service) so you'll need a server-side language, and since you are a beginner, you may want to look into PHP which I think is approachable. Within that there are several PHP frameworks for data, and several for templating, and several with both. Many of the full frameworks (in any language) are geared for experienced web devs. That said, I like the twig templating language for PHP
This, I think, is a good place to start http://www.phptherightway.com along with the super popular but basic W3schools. The link above I think organizes the concept a little better.
You can install the stuff you need on your laptop for that standard (and old school) 'LAMP stack', or use one of the many hosting companies, nearly all of which provide everything you need. good luck learning!

How to Order management in ecommerce module for Orchard CMS

I'm developing an e-commerce module for Orchard CMS.
I cannot make decision for creating Order and OrderDetail as ContentPart or simple table.
What is best solution for implementing order section?
Please Help me and say your opinion and reasons.
As Bertrand points, I think that you only should make a ContentType entity that will take advantage from the Orchard's feature (or for faster admin development if isn't a heavy app). Be aware that the ContentItems are too abstract, so it has some penalisation (just use the debugger and you will see what happens).
Furthermore, are you aware that Orchard already has an ecommerce module? Try to follow DRY, and if you don't want to use it, at least, you should see the source code (Nwazet.ecommerce).
It really comes down to whether or not you want your Orders to be content items or not. As content items they can benefit from using features designed for use with Orchard. Some examples include indexing, built-in permissions, and dynamic type definitions.
There are sometimes reasons when you wouldn't want a model to be a content item. Maybe, for example, you might want to move your order system out of Orchard at some point. Not relying on Orchard's built-in features for order management might make that process easier.
Personally, I like to default to using content parts because I really like the Orchard architecture and I feel that it saves me a lot of time with boilerplate code. I only switch to using bare models after discovering a clear reason to do so.

Rails vs Backbone: Who should be responsible for templates and views?

As an exercise, I intend to replace all front-facing aspects of my Rails application with Backbone.js. Part of the plan includes redesigning everything right down to the CSS.
The issue I'm struggling with is in delegating responsibility for templates and views.
Is there any benefit to implementing the new front-end entirely in Backbone, hence only using Rails as an API?
How do I strike the right balance between Rails and Backbone when it comes to handling the HTML elements of the application?
Since it seems that nobody is going to post an answer to this I'll offer my two cents as just one point of view (I've written elsewhere about the issue of how to get rails and backbone.js to work well together: rails and backbone working together).
Most people in this situation will tend to drop the rails views altogether and migrate everything to backbone.js.
This is what I've done in a project that I'm working on right now.
This is the natural course of events, and particularly once you start getting used to all the complex interesting things you can do with backbone.js and structured javascript, it becomes difficult to turn back and implement standard stateless HTML pages.
As I mentioned in my other answer linked to above; however, there are costs to completely abandoning HTML views and the stateless layer. In my case, I intend to add back pure HTML pages for non-js-enabled browsers for GET requests only once the app has reached a certain level of functionality. We won't support POST or PUT requests unless the user has javascript enabled (or unless they want to go through the JSON API).
That's the balance I've struck: stateless HTML (no-JS) for accessing data, but JS required for posting/changing data. Your choice will vary depending on your use case and target user.
The other thing that I would mention is that if you have been working with rails HTML views on a project for some time, you might be unprepared for the initial overhead required to switch to backbone.js. This is not simply swapping HAML for ERB: you are migrating from a stateless front-end to a stateful one, and that is a potentially huge change (depending on the complexity of the app). I myself was a bit unprepared for the depth of that change, and had to do a lot of catching up before getting our app back on track after making the switch. And we made the switch very early, with minimal functionality already in-place.
Anyway just a few thoughts, hope they help.

JSF (and friends) tags vs. traditional html tags

So this question came up today and I didn't have a specific or scientific answer.
What are the costs associated with using jsf (or tomahawk, faclets, etc., etc.) tags in place of traditional html tags. My gut reaction is that you should use jsf tags in situations where you need the additional functionality they provide, and use traditional tags when you don't. Also I feel like jsf tags would require more resources (since the server has to take them and rerender them as html anyways) than html. Does anybody know what the cost actually is (as far as time and memory)? Also useful information is what is the convention that is in use, pure jsf or a mixture of the two?
Sure there is a cost. Whether that is noticeable or negligible depends on the hardware and the load of the server in question. Profile it and upgrade the server if necessary.
You should however realize that on the other hand you save time and cost compared to implementing the same without help of a component based MVC framework. That's going to be a lot of boilerplate code gathering the paramters, doing validations, conversions, updating model values which is possibly not written efficient as compared to existing and widely used MVC frameworks.
The Sun JSF development team puts performance as high priority and Mojarra is already optimized as much as possible.
Our site http://www.skill-guru.com runs on JSF/ Tomahawk / Rich faces on a tomcat server. We do not see any speed issues here.
As Jeff pointed out , it all gets compiled so there is not much noticeable difference until and unless you really use too much rich faces or other fancy stuff.
JSF does help you make your life easy.
A JSF page gets compiled upon first request (or pre-compiled if you specify that in the config). Thus, it's not like the page needs to be parsed every time it's requested. I don't have any specific numbers relating to time/cpu/memory cost, but I'm sure it's negligible.

Rapid web application development with a Web Toolkit

I spend a lot of time (actually too much time) developping back-office applications whose main purpose is content management and web application configurations. Here is how I can describe these apps :
- Made with PHP
- Using a MySQL or Postgres or SQLite database
- Made of a lot of pages and features
- Very simple features, mostly data CRUD (create+read+update+delete into the database)
- Mostly made of forms
- UIs are usually quite simple (html + css + very basic javascript)
All of the data access code in these apps relies on a library I developped years ago and re-use every time I can. This part is not time-consuming.
What's time-consuming is the UI part, and mostly designing data-lists and forms. Using a WYSIWYG editor would make a lot of sense here, except those I tried (Dreamweaver, Frontpage, Expression, Eclipse, ...) don't really make it much faster, because the generated code is often bloated, and these tools can't rely on custom libraries such as the one I made and use.
I figured using a Web Tookit could be another way to spend less time developping these tools. So before I spend too much time looking for the perfect toolkit, I would appreciate your opinions and experiences on that kind of matter.
Disclaimer : I'm not looking for advices on how MVC is the way to go and how CodeIgniter/Zend/WhatEver is the framework I should use. My question is not about the frameworks or the design patterns I should build my applications upon. My question is about using the right tool to make simple web-applications development faster, and their code even more re-usable.
Is there an awesome web-application RAD tool I don't know about ?
Which toolkit do you use for simple but form-heavy web applications ?
Are there good, light, non-bloated, reliable toolkits written in PHP ?
Thanks in advance !
Edit : Not getting much feedback so far :/ I'm aware that my question is very broad, but I'm sure lots of people work on the same kind of projects I'm talking about, and have improved their productivity by using toolkits such as GWT, Wicket and such. Tell me about it, please :)
September 28 edit : Thanks everyone for the interesting answers. What I'm looking for is not covered by any framework I could try in the past months. PHP is probably not the best language to use for my vision of RAD, but since it's a language I know very well, and since I don't want to spend too much time learning Python as well as I know PHP (for the moment), I decided to do it by myself. Everytime I have a specific need for a widget, I code it in the most re-usable way...so far so good :)
I might open-source that toolkit at some point, and will let you guys know.
The PHP project I've been working on the past few years is a lot like that. Heavy on forms, heavy on server-side logic, but lots of redundant form coding. Too make matters worse, it wasn't all forms, sometimes we actually need to do fancy layout (even just doing a tree control is a pain without a library), and the home-grown nature of the UI meant that I would be battling browser quirks from start to finish.
So, I got to thinking about what a better architecture would be. We needed very powerful form controls, rich grids, rich trees, advanced layout, and we needed to migrate to that gradually. None of the PHP frameworks seemed to fit. Then I took a step back and realized that it didn't have to be PHP, it could be javascript also. We already had a requirement on javascript, so it was fine to go the distance with it. First I looked at the smaller libraries, jquery, prototype, but it became obvious that they didn't do enough. So I looked at Dojo, ExtJS, YUI, all the really heavy javascript toolkits, and settled on ExtJS as having the best controls.
We had a UI structure that relied heavily on iframes, a navigation frame on the outside, application frames inside that, feature frames inside that, and so on. What we ended up with is we're migrating those from the outside in. It's all becoming ExtJS, and it's all living in the same page. The server-side code is kept the same, but it's migrated into web services. At the same time we've integrated zend framework, and are porting some of the stuff you really shouldn't do home-grown to it, like authentication and translation.
The end goal is being able to write just the business logic without having to mess with all the boilerplate. It's too early to know if my approach will pan out, but I think my message would be to be critical towards your code base and decide which parts you want to keep writing yourself, and which parts you want to outsource to a library.
Please try http://agiletoolkit.org/. I think it's what you need. Results with minimum time/code.
At the moment I'm using a solid forms class to render HTML forms with client- and server-side validation, and a database class to write the SQL. I can get a CRUD section of my admin console up in about 10 lines of code. I wrote those classes myself so I can re-use them in all my projects. Hopefully that gives you some ideas?
I would stay away from WYSIWYG tools personally.
I'm testing NuBuilder.com, I discovered it does
within days, at first looks promising. If you take a look
please send me your feedbacks!
Maybe adopt or create an "app-based" infrastructure like Django's? In Django's case, the community has created some powerful baselines like Pinax.
I think Symfony may be the way to go because, like your apps:
it's written in PHP
ORM based on Propel/doctrine (so you can use MySQL, Postgres or SQLite)
Architecture and patterns used will help you with complex applicatons
You'll find tools helping you to debug, document, and test your application
Forms creation, validation, l10n & i18n, testing, AJAX is easy (forms within symfony explained here, check it out)
prototyping you webpages while developing your application is easy
Other tools/practices implemented in the symfony framework that will make your life easy:
full configuration using YAML syntax (easy to read and understand)
the scaffolding feature generates for you a simple CRUD interface for editing your data.
you don't have to worry about coding form sanitization, security, caching, ACL; configuration is needed, but no heavy coding.
The only downside, you need to read some documentation to understand "the symfony way of doing things". But hey, a good framework is 20% code and 80% good practices.
My point is, even if you don't want to use Symfony for your project, you should check its features and built-in tools, because that's the kind of tools you want for your project.
I started using Django and it has very helpful features, esp. the built-in admin (for general CRUD stuff) and really great form-handling code & widget rendering. I'd suggest taking a look, even if you don't plan on using python, just to get an idea.
You mentioned that you don't want advice on "Use X framework", since this is more about RAD & UI/forms than system architecture. But I've found that a good framework helps just as much with the UI & forms side of things as it does the architecture. That means that while frameworks are great for big projects, they're also very helpful in reducing code redundancy. I started creating my own helper functions in PHP that I would copy from app to app that would automatically render an HTML form based on a few parameters. Even after a lot of work, this was very rudimentary compared to what Django offers, and basically I was writing my own framework.
I think you may be looking for a GUI-style tool to help, but you might find that a good PHP framework is more helpful in this case. At the very least, have you tried creating your own helper libraries? I know those helped me a lot.
Simple Example:
function renderInput($name, $value="") {
print "<input type=\"input\" name=\"" . htmlentities($name) . "\" value=\"" . htmlentities($value) . "\" >";
}
function renderRadios($name, $value="", $choices=array()) {
for ($choices as $cvalue) {
print "<input type=\"checkbox\" name=\"" . htmlentities($name) . "\" value=\"" . htmlentities($cvalue) . "\" " . ($cvalue == $value ? "checked" : "") . ">";
}
}
And build up from there. Stupid things like this tend to make form creation just that much faster. A good framework will blow this out of the water. And I'm sure the above has some typos, I haven't done PHP in a little bit.
If this isn't what you're looking for, could you add some more to the question? I'm curious.
Although you're asking for PHP + MySql, I would like to recommend you to give a try to the OutSystems Agile Platform.
You can create a simple CRUD app in less that 10 minutes and grow it as you go to a more complex system.
Download the Community Edition for free at www.outsystems.com.
Best,
Not sure but looks like Tibco General Interface (http://www.generalinterface.org ) is what your looking for.