eZ Community » Forums » Suggestions » What about a "website" class ?
expandshrink

What about a "website" class ?

What about a "website" class ?

Friday 07 October 2011 12:13:30 pm - 11 replies

On a fresh eZ 4.5 installation, the new website starts with a frontpage content object.

The setup of this new site is stored in ini files. Are ini files the right place to store this data ?

Wouldn't it be nice to store some configuration data in a content object representing the rootNode of the new website ? So administrators could change it easily without modifying the ini files ?

We could add title, meta data (keywords, description, author...), logo...

You are gonna tell me "Ok you can do it if you want" but what's the use of "template look" and "Common ini settings" classes ?

Lot's of questions... Let the discussion started !

Modified on Friday 07 October 2011 12:15:47 pm by Franck Grenier

Friday 07 October 2011 12:28:25 pm

One of the first things we do on some implementation is to create a object (e.g. class global_layout) with all settings you describe and more happy.gif Emoticon

Would be nice to have such a thing out of the box, of course.

Friday 07 October 2011 2:35:51 pm

In my opinion, such objects should represent the root of websites. I don't use frontpage as rootnode.

The next question is : Should site settings like meta or title be set in ini files ?

Friday 07 October 2011 2:49:04 pm

Template look class was built for that purpose, iirc. And the "design" tab in admin interface was meant to be the place for editors to change visual elements of the site.

But it was deemed not be good enough, mostly because it was not complete, and because every website has its own separate needs in terms of which visual elements the editors should manage.

This was imho a good choice - I would in fact go as far as remove the "menu management" page that is still present in the admin interface.

But I think that a dedicated "design" tab is a good idea - the only problem is finding the best way to make it flexible enough for most usages and simple enough to maintain.

In fact, I'd like to be able to put the "structure" nodes commonly used as containers for elements but that need no web page by themselves in a dedicated design content tree...

Friday 07 October 2011 2:54:42 pm

In my opinion, such objects should represent the root of websites. I don't use frontpage as rootnode.

The next question is : Should site settings like meta or title be set in ini files ?

IMO single title and meta are useful only on very small site. You need to have ability to set a custom title and meta for every page (node) so these attributes should be on every node that is visible as a page. Not just on one general object or ini file

Friday 07 October 2011 2:58:50 pm

But I think that a dedicated "design" tab is a good idea - the only problem is finding the best way to make it flexible enough for most usages and simple enough to maintain.

In fact, I'd like to be able to put the "structure" nodes commonly used as containers for elements but that need no web page by themselves in a dedicated design content tree...

IMHO there is a big flaw in eZ with the ezflow implementaion. eZ Flow should have been developed as a module not a datatype:

  • it is about layout, not content
  • all nodes could use the ezflow module
  • you could build a design tab for managing ezflow layouts and applying them to subtrees

Now that would be something!

Friday 07 October 2011 5:54:38 pm

@ All

I have also (recently) used the "template look" class to store content/settings/options within it.

It worked very well for us, your results / needs / requirements may vary ...

Cheers,

Heath

Modified on Friday 07 October 2011 5:56:38 pm by // Heath

Saturday 08 October 2011 12:06:06 am

@Ivo I do not completely disagree with you, but you can use ezflow to manage side columns (in the pagelayout) if you want:

  1. set up a "side column" content class with a layout attribute. Allow it to have a single, one column layout
  2. create as many cols as you want in a dedicated area of the content tree. Make sure they are not accessible directly via content/view/full/xxx (use eg a tpl that redirects to homepage)
  3. use object linking to link any "side col" you want to any node
  4. in node/view/full.tpl, do a walk from current node up to content root, looking if there is a related side_col object. If it is there, store its id in persistent_variable
  5. in pagelayout, look at the value in the persistent_variable to find the right side column object to display, fetch it and display it
  6. take care about cache expiries / cache blocks for the side column

Saturday 08 October 2011 12:40:13 am

@Ivo I do not completely disagree with you, but you can use ezflow to manage side columns (in the pagelayout) if you want:

  1. set up a "side column" content class with a layout attribute. Allow it to have a single, one column layout
  2. create as many cols as you want in a dedicated area of the content tree. Make sure they are not accessible directly via content/view/full/xxx (use eg a tpl that redirects to homepage)
  3. use object linking to link any "side col" you want to any node
  4. in node/view/full.tpl, do a walk from current node up to content root, looking if there is a related side_col object. If it is there, store its id in persistent_variable
  5. in pagelayout, look at the value in the persistent_variable to find the right side column object to display, fetch it and display it
  6. take care about cache expiries / cache blocks for the side column

happy.gif Emoticon of course you can dot it like you wrote. We are doing it in similar way.

My point was that it should have been even more easier and more natural to do from within admin interface without using classes nor datatypes.

Sunday 09 October 2011 1:48:22 am

Interesting discussion! Should 'settings' be stored in 'content' classes in the first place? I agree with Gaetano, they are very flexible and thus very handy for all kinds of purposes, especially in large sites, but they can be hard to locate in the structure. These classes with settings should be displayed in a more separate fashion. I think to have a separate view and tab for settings structure and content structure in the admin interface would be a nice approach.

As for eZ Flow: I think structuring your layout should be done on the node level and not in an object/datatype. But this part of the functionality eZ Flow offers should be in the kernel. Blocks are just a view, and eZ Flow isn't limited to 'block'. Dragging and dropping objects/views in place on pre defined (or definable?) areas out of the box would be a huge usability improvement for eZ Publish. The concepts of 'embedding' other objects and custom tags, while again very flexible, are still hard to grasp for many editors. It would be nice to be able to structure the layout of a page in a more natural way instead of by using paperclips.

Modified on Sunday 09 October 2011 1:50:01 am by Sander van den Akker

Sunday 09 October 2011 5:49:53 am

The reply has been removed because of violation of forum rules.

Sunday 09 October 2011 10:25:32 am

As for eZ Flow: I think structuring your layout should be done on the node level and not in an object/datatype. But this part of the functionality eZ Flow offers should be in the kernel. Blocks are just a view, and eZ Flow isn't limited to 'block'. Dragging and dropping objects/views in place on pre defined (or definable?) areas out of the box would be a huge usability improvement for eZ Publish. The concepts of 'embedding' other objects and custom tags, while again very flexible, are still hard to grasp for many editors. It would be nice to be able to structure the layout of a page in a more natural way instead of by using paperclips.

Well said. Totally agree happy.gif Emoticon

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from