Share » Forums » Suggestions » Logic behind eZ templating and design

Logic behind eZ templating and design

Logic behind eZ templating and design

Monday 09 February 2009 12:59:18 am - 6 replies

Author Message

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

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

36 542 Users on board!

Forums menu