Separating frontend development in Symfony2 framework - css

Question

We have software developers (PHP, SQL) and web designers (HTML, CSS, JS, Foundation, Bootstrap) in our team.
A typical scenario: a software developer implements the business logic while the design is done by another person.
Problem: whenever there are changes in the frontend design, the designers have to send new designs to developers, they have to track changes and modify the sources.
Question: what tools/approaches are available to allow designers to work with the Twig templates directly, and apply changes to HTML/CSS/JS without backend developer help (without Symfony and LAMP installation, if possible)?
Or on a higher level - what is the best practice to separate backend and frontend development in Symfony 2?

Answer 1

Or on a higher level - what is the best practice to separate backend
and frontend development?
The frontend team, can work in the templates and send you the markups and then the backend developers will decorate it with the data, that is how it is usually done.
BUT:
The best approach that you can take to separate totally the 'Backend' work from the 'Frontend' work is doing it. :
Create your backend logic to serve the data at demand (Web service / API), instead of serving the views, send a response with a clean body that contains only the data in a readable format, like json objects.
Then the frontend developers can make the corresponding request to the web service to get the data and decorate their templates with it.
The only thing that you need to do is to provide them with the URL that will provide the data for the template that they are working, and the expected output/format that they will be receiving when requesting that url, so they do not even need any server working, they can mock your response while they are testing / creating the view.
Personal opinion:
I think that even for simple applications, this approach is great.
Why?
If you create your backend as a Web Service / API, then it would be easy to expand it, at some point your application would be used by third parties applications, or you just want to create a native mobile application version, or whatever. If that is the case you don't need to re write nothing.
Short History
I've seen huge proyects that were supposed to serve a web page, then it become populars and it ended with more usage from third parties than the web itself and were not prepared for that. They ended developing a web service, with half of the functionality for the third parties apps, and for each functionality that they added to the web service layer they used more code, more testing, and so on..
Come on, still writing?
Talking about web development, you can keep your frontend guys focused on display the data, style, and events of the page, while the backend guys keep focused in adding new features, so no one needs to distract the other side team just because they don't know how a tool from one side works, that for me worth the time that is saved.

Answer 2

The only "best practice" that I could recommend is to talk with the web designers and understand their needs.
Because TWIG is almost pure HTML
This is just plain wrong. TWIG may look like HTML but it's all about the data. Ask your designers if they would be happy seeing something like this in the browser instead of actual data:
List of Products
{% for product in products %}
{% endfor %}
Somehow I just don't think that will work for them.
I suppose there might be a tool out there somewhere that can convert TWIG into real HTML but what to use as data? If it does not match the back end data then problems will ensue.
I would suggest that you will need to teach your developers how to use composer update as well as your source control system. The database should not be a problem. You can have a single designer database somewhere that the back end folks can keep up to date. Someone else can install and configure the LAMP stack,
You could even setup virtual designer machines (perhaps with vagrant) that will be fully loaded with whatever software your designers needs for a specific project. Your developers might find these virtual machines useful as well.
The other approach is the nuclear option. Don't use TWIG. Your back end turns into a web api and only deals with data. No back end generated html at all. Your designers now have complete control over the front end. Bit radical perhaps but it does seem to be the way the industry is moving towards.

Answer 3

Twig is related to Symfony controllers for the "data".
If your designers wants to modify a html part of the twig templates, they can do directly into templates.
If they want to add additional elements which are related to specific data, the should work with backend developers in order to update controllers code and populate this data from backend to front-end part.
If you use symfony to provide only data (JSON based on lot of AJAX Requests from front-end) I think that designers can work alone with interface and mock JSON data in their local installations without using symfony code.

Answer 4

There is no "best practice" to separate backend and frontend development in Symfony 2, simply because it uses the MVC pattern, which in itself separates buisiness logic from views. All your views are gathered in a single directory, and the only job your designers will have is to display the data. Controlers and all the backend stuff is gathered some place else and is invisible to them.
Symfony is not an obligation (although it is the perfect tool for what you want to do right here), but I'd recommend you choose a framework that implements the MVC pattern, because it is the cleanest way to develop, and assures your code to be maintanable a long time from now.

Answer 5

I will share our solution/practice out of PHP, which completely separate the front-end works from the back-end and our designers and developers are separated in different departments, they are connected by redmine's tickets, but they do not need to communicate to each other in most cases, and also their work will not interact with others in most cases.
Out solution is based on java/javascript, simply we developed our own framework to combat with the issue about separating front from back. Currently we have two independent frameworks for this issue, one is for server side rendering by Java, another one is for client side rendering/binding by javascript, a client javascript MVVM framework.
At first, the basic idea of our frameworks is separating all the template rendering logic from the html template, thus our html templates are real pure html files, without any back-end intrusion.
The second step, our designers will complete their works on the independent html files without any consideration of back-end logic. Then at the same time, our back-end guys will write the back-end rendering/logic by separated java/js source.
Assume we have a html file like following:
<div><input name="name"></div>
<div><span id="name-preview"></span></div>
We will perform the server side rendering by java as following:
Render.create()
.add("[name=name]", "value", user.name)
.add("#name-preview", user.name);
Also we can perform the client 2-way binding by javascript as following:
Aj.init(function($scope){
$scope.data = {};
$scope.snippet("body").bind($scope.data, {
name:[
Aj.form({name: "name"}), //bind the $scope.data.name to input[name=name] in 2-way
"#name-preview" //bind the $scope.data.name to #name-preview in 1-way
]
});
});
As in the above examples, we use common css selector to describe where and how we want to render/bind our values to.
At a matter of fact, in our practice, over than 90% front-end refactoring would not need the help from back-end side. Even in the left 10% cases that our back-end guys have to fix the broken rendering/binding, the fixing would become very simple because we just need to change the target css selectors in most situations.
At last, although we implement our server side framework by Java, we believe it can be ported to any other languages such as PHP, ruby, python, etc.
The server side framework:
https://github.com/astamuse/asta4d
The client side framework:
https://github.com/astamuse/asta4js