- Publié le 14 octobre 2011 à 21:20
I've seen this question for the datetime operator lately on Google+. This is a very common question that has an easy answer whenever you know how the eZ Publish template operators are working internally.
If you look at the tutorial on how to write a template operator in an eZ Publish extension, you'll notice that you have to declare in an array that a given set of template operators is implemented by a given PHP class. This system is valid for extensions but in fact, it's also how the stock template operators are declared. The only difference is where the eztemplateautoload.php files are located. For the stock template operators, those files are in the directories listed in site.ini/[TemplateSettings]/AutoloadPathList[] and not in the autoloads sub-directory of each extension declared in site.ini/[TemplateSettings]/ExtensionAutoloadPath[].
Given that, it's easy to find where the datetime operator is declared for instance with the following command:
$ find . -name eztemplateautoload.php -exec grep -il datetime {} \;
# looking for file named eztemplateautoload.php containing "datetime"
./lib/eztemplate/classes/eztemplateautoload.phpAnd by looking at this file, you can see that this template operator is implemented by the class eZTemplateLocaleOperator and the autoload file or your favorite IDE will then show you where it is located in the eZ Publish directory.
- Publié le 23 février 2011 à 09:37
The starting point of this post is an interesting asking of Marty_Nim (aka Nicolas Martinez) on Twitter about the ability to split static components across domains with eZ Publish to improve frontend performances.
Why split components across domains ?
Split components across domains is one of the advices of the Yahoo! Exceptionnal Performances team. This advice is a consequence of the behaviour of browsers that are able to download a limited number of compoments on a given domain at the same time. Following the RFC 2616, old browsers like Internet Explorer 6 or 7 are only able to download 2 components on a domain in parallel while modern browsers (Internet Explorer >=8, Firefox >=3.x, Chrome, ...) are able to download 6 or 8 ressources in parallel. Therefore, this rule is especially useful for those old browsers or if your pages use a lot of different components. It's also not recommended to use too much different domains because of the DNS resolution latency.
In eZ Publish
In eZ Publish, it is very easy to implement this advice for JavaScript files and CSS stylesheets provided the ezjscore operators (ezcss* and ezscript*) are used to include those files. In fact, the ezjscore extension allows to specify a custom hosts depending the extension of the included files. For instance, it's possible to write the following settings in an override of ezjscore.ini file :
[Packer]
CustomHosts[.js]=http://media1.pwet.fr
CustomHosts[.css]=http://media2.pwet.fr
With those settings, eZ Publish will include the JavaScript file(s) from http://media1.pwet.fr, while CSS stylesheets will be included from http://media2.pwet.fr. The later case has an interesting side effect, because the background images used in the CSS files will also be fetched from the custom host.
And what about others components that are directly embed in templates ? Currently, there's no out of the box solution, but as explained by Gaetano on Twitter, since eZ Publish 4.4, it's possible to override template operators so it's possible to write something similar for images, flash, ... embed with ezimage, ezdesign or ezroot template operators even if this should probably be a native feature.
- Publié le 26 novembre 2010 à 23:06
I answered this question by email some weeks ago, it's not a good practice but sometimes it's the only solution... In fact, overriding a default eZ Publish template operator is possible since eZ Publish Fuji (4.4) with a patch I proposed in the issue #16265. It removes the include_once calls to let eZ Publish uses the autoload system. So it's now possible to override the PHP class that provides one or several template operators like any other class in the system. Here's a quick tutorial on how to override a template operator :
1. Enable the kernel override by putting the following line in the config.php file in the eZ Publish root :
define( 'EZP_AUTOLOAD_ALLOW_KERNEL_OVERRIDE', true );
2. In an extension, copy the PHP class that provides the template operator you want to override. To easily find the class, you can have a look at eztemplateautoload.php in kernel/common or the one in lib/templates
3. Make your modification in the copy of the class
4. Generate the kernel override autoload array with the following command :
php bin/php/ezpgenerateautoloads.php -o
And that's all folks ;-)
- Publié le 26 novembre 2009 à 23:23
The big new feature of the roadmap of eZ Publish 4.3 is a new admin interface. The work on it has started with a requirements document and a prototype of a page (download it locally if you want to see it in your browser). jQuery is used in the prototype, I don't know if it's a definitive choice, but as I have already said on that topic, a choice of a framework is better than no real choice (even if jQuery is not my preferred JavaScript framework). I think that most of the big needs are already covered in the document but there are some small details that miss in the current admin interface that I would like to see in the future one :
- Labels of each field should be linked to their related input with the for attribute. That's a very small addition but I find it more than useful in web applications.
- The focused input should be highlighted with a different colour. This is another very small improvement which can greatly improve users experience.
- Buttons in the admin interface should be of a different colour depending on the action they trigger. For instance cancel buttons can be orange, publish buttons blue, remove buttons red, ... The main key here is to be consistent over all the interface.
The edit interface of each datatype should also be considered individually to provide the best interface. For instance, the edit template of a datetime attribute should provide a JavaScript calendar (like with the ezwebin package), the template of a time attribute a button to fill inputs field with the current time, the keyword datatype an autocomplete input (like with the ezkeywords_autocomplete extension), ... Beside an advanced edit interface for each attribute, the data entered in the edit form should also be checked with JavaScript (required or not, valid syntax, ...). In case of errors, fields that do not validate should be highlighted with a message until a new valid value is entered. Obviously, if JavaScript is disabled, a server side check should do the same thing. On this topic, there's also a very old feature request in the issue tracker about the ability to add an help text in the class definition that would be displayed under the edit interface of the attribute.
Finally, a great improvement would be to apply general rules on performances frontend. I think of packing and minifying CSS et JavaScript files (with ezjscore !), using CSS Sprites for design images and use optimized PNG files instead of GIF files. This would improve the user experience by speeding up response time and making the admin interface usable with a slow Internet line
