Feature #146
openIntegrate a template system
Description
We need to implement a template system in order to have more freedom on the layout part.
We still need to make a decision on the template engine between the phpbb template engine or the smarty template engine.
Updated by Hans De Bisschop over 13 years ago
- Assignee set to Hans De Bisschop
Personally I only know the Smarty and phpBB templates engines. I personally prefer the phpBB template engine, Smarty seems extremely complicated when compared to phpBB, I'd be interested in more opinions on this. I tend to remember Alexander Hu not being in favour of Smarty.
Updated by Sven Vanpoucke over 13 years ago
I prefer the templating engine of phpBB as well. I've worked a couple of times with the phpbb 2.0 generator and even wrote our application generator with help of it. It's very easy and lightweight to use (only one class). Though it is more limited in functionality than smarty. But we would need the opinion of more advanced users who work with templating engines.
Updated by Alexander Hu over 13 years ago
Hans De Bisschop wrote:
I tend to remember Alexander Hu not being in favour of Smarty.
Indeed.
This is based in long-time-experience with smarty :-)
Well, both systems have their aspects:
Smarty is A LOT OF CODE AND WORKAROUNDS, because sometimes it is not possible to split code and template due the fact of modular extensions.
(i.e. i had a client yesterday which got really mad about this)
Unfortunately, the understanding of how Smarty works is pretty easy.
But, in my projects, the load times are not always the best...
(in the background, there is always "magic", and this takes a while)
And talking about phpbb engine:
I have tried it, nice to play, easy to use.
But not that many features like Smarty has.
Maybe we don't need all the magic features, we just need pretty and clean code.
Smarty is LGPL, phpBB is GPL, so it would also be handy to prefer last one.
For all others, which are interested, how the phpBB engine works, here is a simple tutorial:
http://www.aurorapod.com/tutorial.php?id=19
http://www.aurorapod.com/tutorial.php?id=20
To understand Smarty, visit:
http://www.smarty.net
A lot of code and examples, but sometimes you get VERY ANGRY about some missing bytes... ;-)
Updated by Nicolas Rod over 13 years ago
That's a great new to know that you think it would worth spending some time to reorganize the code in order to get a better separation between business logic and presentation. As some of you you may know, this aspect is one of the main points that IMHO should be improved in the current code.
Chamilo tends to be a large application and will probably get bigger and bigger. To be easily maintainable the code should really be separated in layers. As you say, it would bring more flexibility in the layout, but it would also bring more code reusability and scalability.
My opinion about what should be reviewed does not only concern the layout but goes a bit further: I actually think that implementing a templating system would be a good opportunity to rethink the way forms are generated and mostly validated.
As you pointed it out, the forms are so far generated with the help of QuickForm. IMHO although QuickForm may be interesting for small projects, I don't think it is suitable for larger projects such as Chamilo. The main reason for this is that it mixes form presentation and fields validation. IMHO these are two tasks that should definitely not be placed in the same application layer.
To illustrate it with a concrete example, I recently wrote some code to import Document objects from Fedora external repositories into Chamilo. This import process creates new objects in the Chamilo user's repository. But before saving a new Document in Chamilo, I wanted the system to check that every mandatory property had a valid value. Such a validation already existed in the case of creating a Document through the Chamilo repository web interface thanks to QuickForm. But this import process has nothing to do with any HTML form, so obviously nothing to do with QuickForm neither. Concretely this meant that I could not reuse the validation, although some code had already been written for that in the application.
Then regarding the templating system choice, I'm afraid that I can't help a lot here if you want to choose between Smarty or phpBB. I don't have any experience with them. The few PHP projects I worked on used PHP template files that received PHP variables from the business layer. This means that it was possible to write PHP code in them, and that it was not necessary to learn any template engine specific language.
Updated by Hans De Bisschop over 13 years ago
After doing some reading, I'm seriously starting to wonder whether we shouldn't be using some kind of solution that actually uses PHP as the templating language, instead of an engine that uses it's own syntax. The pros and cons of most of the templating solutions I've read about up untill now are less then convincing to be honest :-S
Updated by Sven Vanpoucke over 13 years ago
we have a wiki page for this now
http://support.chamilo.org/projects/chamilo-20/wiki/Templates
Updated by Yannick Warnier over 13 years ago
OK, thank Sven for requiring feedback from me.
From my experience with templates, I agree Smarty is a bit too complex to get users to actually use it (instead of trying to use workarounds to try and avoid it).
The latest discussion we had about integrating an important library was the one between JQuery and Dojo, and the final decision point (for me) was that maybe JQuery didn't have everything Dojo had, but it was definitely easier to use.
Out of the template concept, we are in the poor district of open-source, as most of the development efforts for open-source web applications go to more popular apps (joomla, drupal, etc) where most of the users of the software (people downloading it) also have development skills. As such, we must do anything in our power to make it super easy for new developers to join. This is arguably already a problem with the chamilo 2.0 code (one developer takes too long to actually understand how it works, making it very complicated to go from the new-module-building-through-XML step to the fix-and-improve-the-PHP-code step).
So I have a clear sympathy for anything deemed as "easier", even if it represents a more limited library (we can always build on top of some easy library).
On the other side, the fact that the PhpBB templating engine is actually not completely separate from PhpBB means that we will have additional work for each update of the engine, upstream. Is that something that can easily be handled?
On the differences between the engines for phpBB 2 and phpBB 3, I would clearly choose 2, for the potential upstream update problem mentioned above. If that works well, we can always upgrade in one year's time if we need the caching.
Finally, on re-implementing a template engine closer to PHP, I am clearly opposed to that solution. There are loads of issues that we will not detect and, being on the poor side of the open-source developers pool, it makes a lot more sense to avoid useless efforts and benefit from the elements of the rich side.
So to me, it is a go on phpBB 2 template engine.
Updated by Sven Vanpoucke over 13 years ago
I would like to quote on that caching that i think it is not to hard to implement caching in phpbb2.0 and it will be much smaller and easier to use then the phpbb3.0 engine. I will do some tests, make some improvements to the phpbb2.0 engine to see how easy it is to implement caching.
Updated by Hans De Bisschop over 13 years ago
Yannick Warnier wrote:
On the other side, the fact that the PhpBB templating engine is actually not completely separate from PhpBB means that we will have additional work for each update of the engine, upstream. Is that something that can easily be handled?
On the differences between the engines for phpBB 2 and phpBB 3, I would clearly choose 2, for the potential upstream update problem mentioned above. If that works well, we can always upgrade in one year's time if we need the caching.
Since phpBB 2 is no longer being developped, I doubt updates would be causing us many headaches. That being said, the fact it is no longer being developed is something which makes me frown just a little.
At any rate some serious wrapper-classes would be needed to make either version of the classes useable. Even more so for the phpBB2 template class then the phpBB3 one. If possible the original class should be touched as little as possible. Some tweaks and changes are unavoidable I think, but if well-documented I doubt they would pose fundamental problems. Some suick reading leads me to believe / hope most changes would revolve around user-objects and paths of files.
phpBB 2's templating syntax seems very limited, maybe a bit too limited for my taste. phpBB 3's feature set is richer without being all that much more complex. Upgrading from phpBB 2 to phpBB 3 on the other hand could be quite complex.
In theory I'm fine with either choice, but we should carefully consider whether it's actually wise to start using an engine from a PHP4 oriented software package for which the final version was released almost 2 years ago. (not to mention a first release of the 2.x branch way back in 2001)
Just my 2 cents ...
Updated by Sven Vanpoucke over 13 years ago
I took the opportunity to write an extension for the phpbb2 template called phpbb2 template cache. It's a basic caching mechanism for the templates compiled code (~ 50 lines of code)
Updated by Stefaan Vanbillemont over 13 years ago
- Target version changed from 2 to 7
Basic implementation is ready. More roll-out is postponed to 2.1 release
Updated by Stefaan Vanbillemont about 12 years ago
- Project changed from Chamilo LCMS Connect to Repository
- Category deleted (
14)
Updated by Stefaan Vanbillemont about 12 years ago
- Target version changed from 7 to 2.1.0
Updated by Stefaan Vanbillemont almost 12 years ago
- Target version changed from 2.1.0 to 55
Updated by Yannick Warnier almost 12 years ago
Smarty has clearly been designed from the start to manage it independently from any specific software, so I would tend to think it's a better choice.
Updated by Stefaan Vanbillemont almost 12 years ago
- Target version changed from 55 to Backlog (default)
Updated by Stefaan Vanbillemont almost 11 years ago
- Assignee deleted (
Hans De Bisschop) - % Done changed from 10 to 0
Updated by Yannick Warnier almost 11 years ago
After discussion with you (LCMS team), we decided (in LMS) to go for Twig. Claroline is also going ahead with Twig. We've seen that it increases the memory footprint considerably (about 14MB of additional memory user for each page when caching is off) but we think it might be balanced by the caching itself.