|
Wednesday 05 September 2007 1:22:19 am
I think you just missed some powerfull features of eZ...
First, you should create your own design rather that complete the "base" one.
eZ use a "fallback" system, that search for a called template in each design of its stack.
This system allow you to just bring your custom templates in a specific design.
Another intersting features is the "sections" one. You can "specialize" a whole subtree by setting a custom section to it.
You just have to go to your admin interface in the "Setup" sheet, to click on "sections" in the left menu, and declare a new one for the "content part".
You can now edit your "Glossary" folder in the content tree, and assign this new section to it using the box in the left bottom section of the edit view. You can now declare an override that won't depend on a node ID (such an override will be broken if the node change).
As said above, the view you have to override for the folder is the full view.
You should have something like this in your settings/siteacess/xxxxx/over[glossary]
[glossary_full_folder]
Source=node/view/full.tpl
MatchFile=full_folder_glossary.tpl # or rather full/article_glossary.tpl, if you create a full subdirectory in /design/xxxxx/override/templates
Subdir=templates
Match[section]=7 # ID of the section
Match[class]=folder
You can now write your specific glossary templates listing articles childrens.
It means that you should at least have :
...
specific display code
...
{* list all children article nodes *}
{def $children=fetch(content, list, hash ('parent_node_id', $node.node_id,
'class_filter_type','include',
'class_filter_array', array('article') ) ) }
{* loop on children and call for their "line" view *}
{foreach $children as $child}
{node_view_gui content_node=$child view="line"}
{/foreach}
...
specific display code
...
Now you should override the "line" view for the class article and for your custom section (when you assign a section to a node, all its child will inherit of it)
[glossary_line_article]
Source=node/view/line.tpl
MatchFile=line_article_glossary.tpl # or rather line/article_glossary.tpl, if you create a line subdirectory in /design/xxxxx/override/templates
Subdir=templates
Match[section]=7 # ID of the section
Match[class]=article Your override work for all articles under your glossary folder, and only for them.
You can also imagine to call for a "custom" view by changing :
{node_view_gui content_node=$child view="line"}
by something like
{node_view_gui content_node=$child view="glossary_line"}
and having an override like this :
Source=node/view/glossary_line.tpl
MatchFile=line_article_glossary.tpl
Subdir=templates
Match[class]=article
(you don't need to match on section because your custom template will only be called by your custom folder template). This system provide a lot of possibilties, you have many solutions to reach your goal.
Just remember a thing :
When you navigate to a node, eZ will call for it's full view.
The standard call of eZ for a full view template of a node is always "node/view/full.tpl" (this template exists, it's the "default" one).
The purpose of override.ini is to define specific templates that eZ should get instead of default one, when given conditions are matched.
When viewing a node, eZ will browse override.ini files until it find a matching rule for it, so it will search in rules about the template it asks : source=node/view/full.tpl.
The first rule with "Match" conditions filled will be used, so eZ will use the template defined in the MatchFile key instead of the asked source (node/view/full.tpl).
It means that order is slighlty important, don't set your "generic purpose" overrides at the top of override.ini, or eZ won't go further. When asking for another view than the full one using, for exemple, the display template function node_view_gui ..... view="custom_view", the asked template become "node/view/custom_view.tpl", and it will search for such source in your override.ini files.
You have to know that you don't have only templates for nodes. You can have some for objects and attributes. And more, you don't have only the view mode. You have the "edit" mode too, and several other ones.
If you want to call for the standard edit view of a given attribute, you can use the display function attribute_edit_gui attribute=my_textline_attribute
In this case, eZ will ask for a "content/datatype/edit/ezstring.tpl", and you can build an override rule for it using this template as source. All is working with exactly the same logic than node/view/full, it's quite powerful if you can understand the basics of this mechanism. I suggest you to activate the debug mode for your site, and display the "List of used templates". It's quite explicit, showing you for each template used in your page, which is the source called, and what template was provided instead of it, according to overrides.
|
