Forums / Suggestions / Applying features to modules and views

Applying features to modules and views

Next topic

Author	Message
Jan Borsodi	Saturday 26 July 2003 5:27:40 am Currently things lik section id, pagelayout template etc. are controlled by the view code. This is OK for views like conten/view which returns values taken from the content objects. However for more 'static' views like search, login etc. the only way to select section ID is to add to the code itself, which in turn makes your code out of sync with eZ publish releases. A way to solve this is have a .ini file in which you specify a module or a view and which features/characteristics you want to add. Possible things to add/change are: - Section ID - Pagelayout template. - Path - Design - Meta data - Navigation part Maybe it's a good idea to able to set values before the module/view is run or after (or both), ie. section ID could be set before it is run and pagelayout after. It could also be a good idea to be able to set values based on view parameters and plain url matches. Any thoughts on this? -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Daniel Staver	Thursday 21 August 2003 1:54:59 am I run into this problem almost every time I set up a site. Especially when I create menus and nagivation elements that rely on section or node information. Would it be possible to allow the user to create instances of the modules anywhere in the node tree through the admin interface? I'm thinking that in addition to the list of classes when you create new objects you could also have a list of modules. That way you could create separate logins or searches for separate sections on the site and they would each inherit the section and permission information for that area of the site. From a user point of view it makes sense that anything you can view on the site also has a physical placement within the site structure, and from an administration point of view it would make things much easier since any type of object could be treated the same way. It should also be possible to create separate override templates for each instance of the module and its related templates. Daniel Staver http://daniel.staver.no
Paul Borgermans	Tuesday 02 September 2003 11:23:34 am This would be very welcome. Just ran into the problem of needing another pagelayout for content/edit. For now, I added a line to the end of the code of kernel/content/attribute_edit.php $Result['pagelayout'] = 'pagelayout_edit.tpl'; Where pagelayout_edit.tpl maximises the space available for the edit form elements. But for the pagelayout.tpl, why not add this to the override.ini function: we only need more match keys for module and function? Or do I miss an existing match key? -paul eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans
Jan Borsodi	Wednesday 03 September 2003 12:03:33 am Using override.ini will work for setting the pagelayout, but it will not work for all the other things I mentioned, such as setting the current section. -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Paul Borgermans	Wednesday 03 September 2003 4:58:41 am Hello Jan I tried the override.ini, but don't know what Match[??] to use for /content/edit. I tried Match[view]=edit, but this did not produce the desired result (in 3.1): the default pagelayout.tpl was used I do support your suggestion, as it introduces more flexibility. Regards -paul eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans