Forums / Developer / Customizing menu branches with own extension?

Customizing menu branches with own extension?

Next topic

Author	Message
Tobias S.	Thursday 30 July 2009 11:39:34 pm Hello, I'm about to use eZ Publish as application framework. The application will arrange large ammounts of rather tiny content, and provide additional features when viewing it. I'd like to attach those customized views directly to the normal node tree, thereby appearing in the menu side by side with normal views. The node tree will look like Main Node Normal View 1 Some Articles Some Articles Some Articles Normal View 2 Some Articles Some Articles Some Articles Custom View Some Articles Some Articles Some Articles The Normal Views will be delivered as usual by the content module. The Custom View should have additional features like filtering content, changing the display order, show additional information and whatever the app requires. Now, I'm not sure how to achieve this and what would be the best approach. Can I somehow tie/attach my own module views to the custom view part of the tree, so it will be invoked instead of the content module? Or can I somehow "hook" into the content module to take over control, perhaps by using sections to distinguish between normal and custom views? Any help or ideas are highly appreciated! Cheers Tobias
Gaetano Giunta	Friday 31 July 2009 1:32:16 am It is not very clear to me if the 'custom view' section of your tree displays in a different way the content that actually lies in the other sections or if it just displays content that is in it in a different way. Regardless of what you want to achieve, you can hook into the content module and take complete control of the output, as long as you take some precautions. The advantage is that you get to keep the tree structure and the moving nodes around / renaming them / adding and deleting them capabilities for free. You can use an override template for both the pagelayout and the node templates of your custom section, based on a variety of factors: a new section, the content class, view mode etc... (see http://ez.no/doc/ez_publish/technical_manual/4_0/reference/template_override_conditions) Some useful tips might include: - take care about view cache for 'meta' nodes, ie. nodes whose templates do not show information coming from the node itself but info coming from elsewhere. You should try to use the smart view cache to introduce proper dependencies or disable the view cache for them and try to introduce some cache blocks to reduce the load - using a view mode as 'special mode' indicator forces you to use the system url of a node instead of the nice url, eg /content/view/mymode/64; You can set up wildcard url aliases to overcome that (and play around with the layout/set module, too) - you might also code a full view for your nodes that, depending on a view parameter, includes via node_view_gui the template for another view mode, eg. user url like my/custom/node/(view)/customized and in the template do {if is_set($view-parameters.view)} {node_view_gui content_node=$node view=$view-parameters.view} {else} ... {/if} - remember that by default only 'full' view mode benefits of view cache, but you can enable it for other view modes as well - an 'http_header' template operator to do redirects from within template come can be handy, eg. for templates that redirect to other nodes views Principal Consultant International Business Member of the Community Project Board
Tobias S.	Friday 31 July 2009 2:36:40 am Thanks for the quick reply, Gaetano. I'll keep all the hints in mind while developing my concept. <i>> Regardless of what you want to achieve, you can hook into the content module and take complete control of the output, as long as you take some precautions.</i> Yes, this is partially what I'd like to do. Template overriding is a great thing and will be very usefull of course! But I think I'll need more controll about the objects to display. In concrete, I think of a tag cloud that is displayed aside the Custom View. As soon as the user clicks a tag, the currently viewed list will be reduced to display only the articles containing that certain tag. And the user may add more and more tags, until the list displays only articles he's interested in. The tags have to be delivered dynamically, depending on what tags the user already has selected. I suspect this is too much for a simple template override, thus I would prefer some kind of PHP hook instead of just another view mode.
Tobias S.	Friday 31 July 2009 5:00:24 am Well, in the meantime I decided to not generate the list views dynamically. Instead I'll generate the "custom view" navigation structure during cron cycles and let the content module serve it, as that's what it does perfectly. Spares me lots of caching considerations by the way :) <b>A single question of this topic is still open (or perhaps I didn't recognize the answer):</b> Can module views be attached to nodes, for a developer to benefit of the convenience the admin site and defaut menu system of eZ Publish provides? Or (to make clear what I suspect) is the only solution to statically link my module's views from inside the templates and therefore, do I have to apply changes to the template code and won't benefit from the admin site's node tree interfaces?
Gaetano Giunta	Friday 31 July 2009 7:08:25 am You cannot easily attach a module view to a node template - using a tpl operator that does http redirects might be one way, but I think that's not what you like to have. You can from within a module's view code redirect to another ez view, but that is the opposite (you coudl from your custom view redirect to a node's content view). But you can wrap the code for your custom views in nice separate content classes, and then expose it for easy reuse as template operators or fetch functions. And nothing prevents you to include the templates done for custom views within node view templates. Principal Consultant International Business Member of the Community Project Board
Tobias S.	Friday 31 July 2009 7:43:08 am I see. Thanks for pointing at fetch functions... overriding the proper content views and calling a module using {fetch} seems to be a very clean solution.