Logic behind eZ templating and design

Next topic

Author	Message
Noicokuna Niemoge	Monday 09 February 2009 12:59:18 am Hello; I'd like to cover one issue: the design of eZ and logic behind it... I just wonder why the default ezwebin design is spread to so many catalogues. It has files in: /ezpublish/extension/ezwebin/design/ezwebin/ (templates, css files) and in: /ezpublish/var/storage/packages/eZ-systems/ezwebin_design_blue/files/default/file/ (images, css files) ... Shouldn't all images and files used by a design be placed in one and only one folder? What if I don't want to create a separate design but only edit the existing one (which is faster)? It's a pain to browse so many folders in different parts of the folder tree. Why images and css files of a design are placed in var folder anyway? They are not changing from the moment of design change. As far as I understand, "var" comes from "variables", which means all the content that is flowing through eZ. Design of the site don't fall into this category... Why not make all the designs in a form of extensions? Designs being an extension is a very handy thing because it consists of autoloaded ini settings as well. The template overrides would be very handy to be edited as well. Something must be done with it, it's very unhandy as it is now. Besides, modifying default design on a test installation of any engine and then exporting it to a new design package is the easiest way of developing a new design for me, for any engine. But eZ is different here, and it's not that EaZy as in some other engines :P. If designs were extensions completely (with all used files in the extension folder), it would be easier to edit and export them/import to another installation. It's enough to make various types of extensions, like: Extension type: design Extension type: enhancement, etc etc. Anyway, just an idea... I really don't like the designing part of eZ. It's not scallable, it leads to unneccessary files all over the place later, which are better left untouched because of "fallback system". Yeah, an excuse :P Fallback system is good, but it's like automatically assuming that many times something won't work, that's why it's better to make it pretend it works. ;) Eh, just joking here of course. Shiki soku ze ku...
André R.	Monday 09 February 2009 3:34:26 am The stuff var/ is for the site style aka design package, something you can change in 'settings' in front end. Ideally design packages should work like this: The base design without all "styles" (colors, borders, background colors / images) should be in the extension. And the design package should define all the style, since design package only contains images and 2 style sheets. webin and flow is however not implemented like this at the moment, making it very hard to create your own site styles, so this is how I normally do it: * For very small site that re uses webin design, create design package if you re use the grey style, and start off with the blue sites style and modify it to your needs if you base it on the blue design. * For small site that has it's own design, create design extension, disable the site style by overriding pagelayout or in the site settings page and override pagelayout.css to suite your needs. * For larger site that has totally different classes and re uses very little to none of the webin/flow design: as above but also override content.css to suite your needs. More on how this can be done is in misc articles in the articles section here on the developer / community pages. eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom
Noicokuna Niemoge	Monday 09 February 2009 5:02:01 am Thank you for clearing it out. :) I hope that in the future the design part of website will be even more separated for easier editing. I can see here possible problems... the templates are strongly tied to content classes, and ezwebin comes with its own content classes. Hmm... it could be possibly much easier if the main design consisted of: 1. Wrapper templates (pagelayout, images, css) - wrapper for a whole site + menu, wrapper for page view, wrapper for page edit, wrappers for uncommon functionalities not tied to content (search, menubars, toolbars, embed etc) 2. Datatype-specific edit/view templates. In this way, when creating a new class and viewing it on frontpage, the system would by default bring up a page wrapper template and datatype basic templates in the order as in the content class. The same would happen if somebody would choose to edit a datatype. The system would fetch an edit wrapper template and edit datatype little templates. In the edit screen of a content class, there could be also a checkbox called "menubar", that if checked would bring up a menubar on left or right. It could bring up some functionalities, like list of children items, calendar display of children items, keywords of children items, etc. (dependant of what datatypes we chose for a class) There could be also a field in each datatype if it should be displayed in embed wrapper, and how (how many characters, how big an image, etc). In this way, when creating a new class, it would not be that neccessary to create class specific templates! Of course then we come up with template overriding, and if someone wants an article looking just as he wants and caching just what he wants, plus creating edit template showing only chosen fields, he creates a template for a whole article class. But he can puzzle it from the little datatype templates, etc, so it's not a problem. So it would be possibly a little step forward to usability. It's just as it looks in admin page, it exactly fetches the datatype templates, am I right? Why not do the same in the frontend? It would be so easier and speed up making a site a lot. :) Then, we would be able to separate templates from our custom design more clearly, and the fallback system would be better (because if it doesn't find a class template, it will just fetch a page wrapper and partial datatype templates.) Plus, when creating a class, seeing immediate results is a big plus. :) Shiki soku ze ku...
Gaetano Giunta	Tuesday 10 February 2009 1:01:12 am <i>2. Datatype-specific edit/view templates.</i> Sorry to break it to you, but that's exactly how it works right now ;-) Every datatype in the system, both standard ones and new ones added via extensions, provide an edit template and a view one (and possibly a few more). The basic <i>existing</i> object template is thus a simple loop that includes in turn the proper template for every attribute. The function to do that is attribute_view_gui, you can look it up in the manual. Of course you're free to create a class template that is very specific and does not do that Principal Consultant International Business Member of the Community Project Board
André R.	Tuesday 10 February 2009 1:36:49 am And the default template in webin (also used by ezflow), does try to show a new class as general as possible so you can style it using css if you don't need to do any 'advance' template logic. webin 1.3: http://svn.ez.no/svn/extensions/ezwebin/stable/1.3/packages/ezwebin_extension/ezextension/ezwebin/design/ezwebin/templates/node/view/full.tpl webin 1.4(trunk, will be part of eZ Publish 4.1): http://svn.ez.no/svn/extensions/ezwebin/trunk/packages/ezwebin_extension/ezextension/ezwebin/design/ezwebin/templates/node/view/full.tpl It will in short try to avoid showing the attributes that are part of the name pattern as that is used in the top of the templates. But the line view and embe view templates are however very basic and probably doesn't fir your needs. http://svn.ez.no/svn/extensions/ezwebin/stable/1.3/packages/ezwebin_extension/ezextension/ezwebin/design/ezwebin/templates/node/view/line.tpl http://svn.ez.no/svn/extensions/ezwebin/stable/1.3/packages/ezwebin_extension/ezextension/ezwebin/design/ezwebin/templates/node/view/embed.tpl But yes, there are a lot of room for improvements in ezwebin / ezflow / eZ Publish when it comes to speeding up development time, so thanks for the feedback! eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom
Noicokuna Niemoge	Wednesday 11 February 2009 11:51:40 pm Thank you very much for reply :) Yes, I saw what the template system can do, it's great :) So maybe it's all about creating a template override for full.tpl class? Can the system automatically, by default, create an override of full class view template when creating a new class? When copying a class, can the system copy the templates of the class that is being copied, rename it with the name of new class and automatically create template overrides? It would be great :) It would be enough to edit the newly created templates. These would be nice additions... Shiki soku ze ku...
André R.	Thursday 12 February 2009 12:25:19 am Can the system automatically, by default, create an override of full class view template when creating a new class? When copying a class, can the system copy the templates of the class that is being copied, rename it with the name of new class and automatically create template overrides? It would be great :) It would be enough to edit the newly created templates. No. These would be nice additions... Yes indeed, but the current system has no real link between classes and templates as the class can have several templates in different designs / siteaccesses, so it would be a complex feature to implement.. eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom