I have an application build with Symfony 3.3 and Twig that will be distributed to more customers. I'm using parameters.yml to customize its behavior and it seems to work well.
Where I have an issue is with twig templates: although the customers will use most of the templates as they are, they'll need to customize some parts like CSS styles, general layout and do occasional design overrides.
The options I have identified are:
Have a full set of templates for each customer. The issue is that the upgrades will be a nightmare as we have to patch each template and account for differences
Customize templates via YML files. The problem is that it gets too complicated soon and the number of parameters is potentially huge
Deliver a set of templates in app/Resources/views and allow the customer to override any of the templates by creating another file with the same name in another folder
Deliver a set of templates in AppBundle/Resources/views and let customers override them in app/Resources/views
Create the application as a Symfony bundle (ie. MyAppBundle) and deploy the application to each customer by including the MyAppBundle via composer. I like this solution a lot, but I do not know whether it is possible to implement is easily.
Do you have any suggestion on how to approach this problem?
I think the best way in your case is to think about the main parts and the customer parts and then build blocks and overwrite all parts that are relevant for the customer for example the CSS or anything else. If you know that there are special part you can build macros for example.
With the Block concept you can predefine the template but the customer has the ability to overwrite that part you've defined with it's own.
With Twig you have a lot of possibilities to solve such a problem.
Drupal 8 use that Theming concept.
https://www.chapterthree.com/blog/twig-concepts-drupal-8-themes-part-ii
Perhaps you can take a look how they have solved that and you can find a good solution for your problem.
Related
I have created a project using plugin skeleton.
Now how can I have a theme working simultaneously with the plugin?
I can create a theme bundle or add view under app
Sylius documentation says -
loading order (priority descending):
App templates:
<Theme>/views (NEW!)
app/Resources/views
Bundle templates:
<Theme>/<Bundle name>/views (NEW!)
app/Resources/<Bundle name>/views
<Bundle>/Resources/views
I can have a theme bundle registered and work simultaneously with plugin in tests/app/AppKernel.php
It depends a bit on your use-case. I'll try to identify some.
1. Sharing plugin with others
In case you want to share your plugin/bundle with others (open source e.g.), it would be best to have the plugin specific views inside your plugin. It allows other developers to override them inside their own theme or inside their app/Resources folder. In case they just like the views, they don't have to do anything besides loading the plugin.
2. Sharing views with other projects
Let's say you want to use your plugin in several own projects, but it might be that some views need to be adjusted. You will still put the default views inside the plugin as mentioned above, but if some need slight adjustments in that project or in some projects, you override them inside that theme. A theme can also be loaded from a repository, therefore making it possible for you to open-source the theme or use it internally in multiple projects.
3. No sharing
In this case I think it's up to your own preference where you place them. Myself I would still save them with the plugin and override them in a theme. In case my very specific app still needs to behave differently, the app/Resources is a last resort. Placing views inside the plugin or inside the theme will allow you to (in case you place them inside a repository) easily also loading them in another project. Besides that, you share responsibilities by grouping functionality together.
Recap
Basically it depends on your needs, but in case you want to share your plugin and/or theme with others, definitely place the files inside the plugin first, and any adjustments inside the theme.
Is it only for internal use? In that case it's up to your preference, but I would still keep in mind maintainability and reusability, therefore placing them together with the part that introduced the accompanying functionality.
We need to customize for example the standard mail invitation template by changing the text a bit. I know this can be done by editing the freemarker template for the invitation that is stored in the data dictionary. This is however not optimal when it comes to application packaging. Is it somehow possible to extend the templates in the manner that they could be put on the extension classpath like the regular extension mechanism?
edit:
Found out that the inviation template for emails are hardcoded in the InviteSender java-class. :(
So I guess we will have to extend that class (and a lot of others) to do this.
Another solution I can think of would be to write a patch that replaces the ftl-files in the data dictionary with our edited ones at install time. Any other ideas?
It has been done and has been written in this blog.
In short No there is no out of the box solution for it.
Yes you could bootstrap your files and Patch Alfresco's (that's the most common used way).
You should also consider the fact that changing a template without to have access to the server where Alfresco is installed is a nice feature. With this functional guys who manage/operate/use Alfresco can change templates to their needs.
Oke so I am about to make a website using symfony 2.
Should I just make a "main" bundle that controls/puts together all other bundles?
With other bundles I am thinking of lets say a "gallery" bundle that controls things related to photos, and a "store" bundle that controls a shop part.
What would be best (or atleast good) practice and how would professional teams do it?
According to symfony documentation a bundle should be consistent and closed structure. So, if for example "store" and "gallery" are related in some way (eg. use the same model), then they should be in one bundle (AppBundle, CoreBundle, PlatformBundle - whatever you want). But if gallery is completely separate piece of code and can be easily join to another project - then you should consider exclude it to separate bundle.
I think a good idea is look at some projects on github and look how others handle this.
See the following questions and my answers to them:
Should everything really be a bundle in Symfony 2?
Symfony2 conceptual issue: general bundles vs. specific ones
Basically, in my last projects I'm not using bundles for app specific code; the only exception is for stuff that's hardcoded to be in a bundle — like Doctrine Fixtures — that I put in AppBundle. Everything else — models, controllers, services, form types, etc — are out of any bundle.
Like #Cyprian said a bundle is a set of functionality that can work alone. As it happens while developing we do not always know when things are separate. It comes with time.
Personally, I am working with Symfony2 since Febuary and I never stopped reading the manual and related books to understand more in depth. That helped a lot and is very interesting read, I assure you :)
Here is my top favourites documentation pages, en enlightening blog posts on delicious.
For your immediate question, forget about "frontend" and "backend" as we were doing in symfony 1.x. Just think of Model entities (as in A SINGLE row) and build in one bundle. As your code will grow, you will see how to disassemble and separate in bundles. You just have to keep in mind to separate your functionnalities in small methods and refactor around.
Oke so I am about to make a website using symfony 2.
Should I just make a "main" bundle that controls/puts together all other bundles?
With other bundles I am thinking of lets say a "gallery" bundle that controls things related to photos, and a "store" bundle that controls a shop part.
What would be best (or atleast good) practice and how would professional teams do it?
According to symfony documentation a bundle should be consistent and closed structure. So, if for example "store" and "gallery" are related in some way (eg. use the same model), then they should be in one bundle (AppBundle, CoreBundle, PlatformBundle - whatever you want). But if gallery is completely separate piece of code and can be easily join to another project - then you should consider exclude it to separate bundle.
I think a good idea is look at some projects on github and look how others handle this.
See the following questions and my answers to them:
Should everything really be a bundle in Symfony 2?
Symfony2 conceptual issue: general bundles vs. specific ones
Basically, in my last projects I'm not using bundles for app specific code; the only exception is for stuff that's hardcoded to be in a bundle — like Doctrine Fixtures — that I put in AppBundle. Everything else — models, controllers, services, form types, etc — are out of any bundle.
Like #Cyprian said a bundle is a set of functionality that can work alone. As it happens while developing we do not always know when things are separate. It comes with time.
Personally, I am working with Symfony2 since Febuary and I never stopped reading the manual and related books to understand more in depth. That helped a lot and is very interesting read, I assure you :)
Here is my top favourites documentation pages, en enlightening blog posts on delicious.
For your immediate question, forget about "frontend" and "backend" as we were doing in symfony 1.x. Just think of Model entities (as in A SINGLE row) and build in one bundle. As your code will grow, you will see how to disassemble and separate in bundles. You just have to keep in mind to separate your functionnalities in small methods and refactor around.
I'm trying to build a template system in CodeIgniter like wordpress. Does anyone have some links or tips to share with me on this matter?
I would like to create several functions that I can call from those php template pages like in wordpress. For example to display the comments from an item or loop through something, or even a tag_could.
the views folder would containt the different template folders & files.
and yes there is smarty, but no I don't want to use it.
Have a look at my Template library. It supports modules, themes, partials and layouts so you can create one main layout for each theme then have modular views if you wish.
While you are not a fan of Smarty, you might be interested in trying Dwoo. They are both very similar but Dwoo has the advantage of not sucking major donkey balls, which is Smarty's main downfall. I have written an extension for the CodeIgniter Parser library to get it to use Dwoo, which integrates perfectly with my Template library.
Between the two you can make pretty powerful, theme-able MVC applications.
Check out
http://www.williamsconcepts.com/ci/codeigniter/libraries/template/index.html
Template is right for you if:
You feel like using views can be clunky, especially when "embedding" views.
You don't like calling header, footer, and other global views from every Controller method.
You prefer having one "master template" that can be changed for any controller in order to meet unique application design needs.
You don't want to drastically alter the way you interface controllers and views.
You like clear, thorough documentation on par with CodeIgniter's User Guide.