eZ Community » Forums » Developer » The top 3 "Don'ts" of eZ Publish?...

The top 3 "Don'ts" of eZ Publish? Any concepts eZ should let go?

The top 3 "Don'ts" of eZ Publish? Any concepts eZ should let go?

Wednesday 09 February 2011 11:04:50 am - 26 replies


This is the forum part of a discussion started on Twitter.

It started with this question from @andrerom :

"Whats the top 3 "Don'ts" of #ezpublish ? Any concepts we should let go?"

I feel it deserves more than 140 char. So here is the topic.


What i think :

  1. ezxml has too many limitation. We should be able to freely build our pages. Limitation should be an option.
  2. template language : i do not understand why we use this layer. I guess pure php could do the same. No ?
  3. Information collection attributes : i dont know why but i feel it could be better.

Modified on Wednesday 09 February 2011 11:37:12 am by Paul Etienney

Wednesday 09 February 2011 11:51:51 pm

Just a note on my side. i agree template language could be better... but i wouldn't like an eZ Publish in which pure php code is merged with html tags.

i've worked with other cms when this is is quite possible (yeah, that cms... happy.gif Emoticon) and sometimes you see codes in wich mysql_connect sentences are merged with <ul> or <div> tags.

mmm... no, i can't see a eZ Publish having something like

<h1><?php echo $currentnode->attribute( 'name' )?></h1>
<?php $nodes = eZContentObjectTreeNode::subTreeByNodeId( array(), $node_id );
foreach( $nodes as $node ) {?>
<li><?php echo $node->attribute( 'name' )?></li>
<?php } ?>

It starts there and it ends trying to do sql queries to directly to content tables...

for me separation between content and design is one of the best things of eZ. admiting that some times it's tedious and frustrating, i still don't know a more flexible one in this part.

+1 for adding the voting possible new features.

Thursday 10 February 2011 2:37:26 am

I totally agree Carlos. The content/design separation is a great concept. When I first discovered ezp, i was super excited to see that the admin was just a different layout. To me this content/design separation and siteaccess are superpowerful concepts to keep.

I am not sure the node / object separation is totally relevant. To me the only case it make sense is when an object is cloned in different location. But i have never used this feature.

Thursday 10 February 2011 10:35:07 am

PHP templates are not THAT bad, it just depends on the coding standards you use. The fact that you can use PHP directly doesn't mean you should use all the features from PHP if you want to maintain readability.

I use them on a project of mine, and this is the kind of code I have:

<p class="foo"><?=$content?>
  <?php foreach( $items as $item ): ?>
    <?php if ( $item->stuff ): ?>
    <a href="<?=$item->link?>"><?=$item->text?></a>
    <?php else: ?>
    <?php endif ?>
  <?php endforeach ?>

This keeps code readable, with the minimal amount of PHP code, and I Have to say I kinda like it.

P.S. I'm by no mean saying we should get rid of a template engine blunk.gif Emoticon

Thursday 10 February 2011 11:13:20 am

I agree with this

"The fact that you can use PHP directly doesn't mean you should use all the features", but on the other hand, my worry is the fact that you can use php directly and this leave, perhaps, more possibility to the developer to go in the wrong way. in other words, i see that like a easier way to introducing hacks in the whole thing... Yeah, perhaps too much strict and too hard to learn, but probably more secure at the end..

and ok, introducing hacks or bad practices is not a problem of phptemplate (in this case). it's a developer problem, but in my opinion, being ez so strict, makes the developer go always in the same railway.

On the other hand, i doubt how flexible could be that. following your example and seeing how i see it in ezpublish, suppose those <li> needs a class for any of your other siteaccess... actually you use fallback design and ok. how should be done with phptemplate, for instance? copying all (html and php) to the new design and so having duplicate code?...

ok, maybe i was a bit crude in my previous post. in fact i use phptemplate sometimes... it's just i wouldn't a thing like that in eZ Publish happy.gif Emoticon.


Thursday 10 February 2011 2:43:21 pm

My 2 pences on the template language :

I think the eZC / Zeta Components template engine is cleaner than the one currently implemented in eZPublish. The main features are the following :

  • The template as an interface you must fill to know which variables are set inside the template. It is very clean and allow you to rapidly know what can be wrong or not in your template. If you're a noob in eZ, you may ask what are $#node or other subtleties in the template. This can also enforce the good practices and the use of already set data, see "Variables in page layout" in the reference. By the way it can be tricky to implement for eZPublish unless having a kind of big table to store everything.
  • In term of i18n and cache, the components already provide "tied in" components that are doing this. If we don't want to use those, we can still made new functions that handle the former PHP functions / operators.
  • In term of syntax, ezc is closer to PHP syntax than the current eztemplate engine.

What is missing is :

  • The content related functions : attribute_view_gui, node_view_gui and so on. Not so difficult to implement.
  • The dot syntax that is very useful in templates. This allows to either access an object attribute, a value of an array or run a function.

Coding for 2 years now with ezcTemplate, I think it can be the best valuable thing that can happen to eZP.

Friday 25 February 2011 5:35:23 pm

Chatting with a colleague : You can definitely remove the Enumeration datatype.


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from