custom content types in Mezzanine

[Gour]

Hello,

when I chatted with Stephen two months ago, he told me that "the idea
of a content type is the same as a page" and yesterday Ken also
provided some nice ideas about custom content types in Mezzanine.

However, I'm coming from Concrete5 (PHP CMS) where the page is divided
into specific 'areas' and one can add as many as desired content type
blocks to each page 'area' where content type blocks are like 'black
boxes' encapsulating specific functionality (e.g. general content, form
block, Google map, Image, RSS block, video player, download list etc.
are some of the blocks available for re-use) and the end-user can use
them like LEGO bricks to create customized content.

Let's take simple page with the following template:

header |
--------------------------------- |
| sidebar
|
main area |
----------------------------------|

and I'd like to put together the following page:


image |
----------------------------------|
| RSS
content (TinyMCE) | ------
----------------------------------|
| Google map
youtube video |
----------------------------------|

iow. have image in the header, RSS & Google map displayed in the right
sidebar and two blocks in the main are: content entered via tinyMCE
editor as well as video player for youtube videos?

Is it possible to achieve such structure easily in the Mezzanine or how
to do it?

What if I'd like to swap order in .e.g main area having first 'block'
with youtube video and then tinyMCE-generated content below?

Does it require new custom structure to be defined?


Sincerely,
Gour


--
When your intelligence has passed out of the dense forest
of delusion, you shall become indifferent to all that has
been heard and all that is to be heard.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Eduardo Rivas]

Well, a solution would be to extend the Page model with unlimited RichText widgets (via a ForeignKey). Each widget will have an option to choose the "block" where it should appear (sidebar, header, footer, etc). You will have to write a template with very thorough conditions to make each widget appear in the desired block.

An alternative way would be to extend or learn from the Forms app in some way. You can see there that the user gets to choose among "Single line text", "Multi line text", "File upload" etc. Something similar could be done with it, for example let the user choose among "video", "download list", "rss" etc. Of course, each one should have it's own model (and registered admin) to manage the correct management and generation of the content blocks. Templates could be managed nicely via template tags and includes.

On a side note, I would like to say I've never considered Mezzanine to be this kind of CMS (where the front end user gets to "build web pages without a single line of code"). I always saw it as a very powerful tool for developers to give clients/collaborators/whatever high quality web applications they could manage easily (all this comes from Django). However, this doesn't mean it can't/shouldn't be done, because who knows, maybe we are witness to the birth of great Mezzanine app :)

[Stephen McDonald]

This last paragraph is spot-on! 

--
Stephen McDonald
http://jupo.org

[Ken Bolton]

Can we get that last paragraph (or something similar) into the documentation?

[Ahmad Khayyat]

On Wednesday, November 28, 2012 1:07:06 PM UTC-5, Kenneth Bolton wrote:

Can we get that last paragraph (or something similar) into the documentation?

 
I second that. In particular, I think it would be very helpful for new comers to clarify the separation of the "site developer" role and the "site author" role that Mezzanine, rightfully, enforces.

[Eduardo Rivas]

Now that you mention it, a while ago I was thinking about creating a new user group, something separate from superusers, like page_admin. This group will have full permissions only over Displayable objects (preventing the group from accessing the settings or other models you might want to keep developer-only). It's just some clients work as teams, and they want to have an "Admin" who can see/change all other users' pages, blog posts, etc; while each individual user has access to only it's own stuff. Am I making sense here? Has anyone faced this issue?

[Stephen McDonald]

Great idea - not sure where it should go. It seems a bit to specific for the overview. Could it be worded differently to be general enough to fit into the initial description of Mezzanine? Perhaps it could go under the FAQs - something like "Why doesn't Mezzanine implement pages with blocks that users can use to build their own pages with?"

[Ahmad Khayyat]

On Thu, Nov 29, 2012 at 11:57 AM, Stephen McDonald <st...@jupo.org> wrote:

Great idea - not sure where it should go. It seems a bit to specific for the overview. Could it be worded differently to be general enough to fit into the initial description of Mezzanine? Perhaps it could go under the FAQs - something like "Why doesn't Mezzanine implement pages with blocks that users can use to build their own pages with?"

It could also be mentioned in multiple places with different context. For example, in the Architecture section, such a comment would explain the Page-centric model, and why isn't there any support/infrastructure for blocks. 

[Stephen McDonald]

Great idea - that actually seems like the best place that text would go verbatim.

[Peter Davis]

Hi,

Spurred on by the discussion in this thread I made a mezzanine extension called mezzanine-flexipage that I would love to get feedback on. 

The summary is that new RichContent areas can be added and removed simply by adding or removing a variable in the template. This means that adding and removing arbitrary numbers of RichContent fields is trivial, and can be done by someone with little or no knowledge of Mezzanine/Django/Python (e.g. frontend designers).

It works by template introspection to find all variables with a particular prefix (currently "flexi_"), then ensuring that a fk'd RichContent Field exists for that variable, and that it gets added to the template context when needed. The best demonstration of the extension is having an existing "FlexiPage", working on the template and adding/removing new RichContent areas and seeing the new content areas appear on the page (after refresh) as you add them in the template. 

Still pretty alpha (admin stuff works but is rather clunky), but I have tested the instructions given in the readme.md and installation should hopefully be smooth. 

Cheers

[Tom Brander]

I'm a real newb on this stuff and monitoring this group in my effort to learn. This looks very interesting I just skimmed the readme, I have been thinking about the various "flatblock" solutions, what are the tradeoffs vs this approach?

[Stephen McDonald]

Thanks for sharing this Peter, it looks really solid.

[Peter Davis]

Hi Tom,

I *think* the main difference is that flatblocks is a versatile way to make changes across your site (via changing the content of a FlatBlock model which is getting used site-wide) and flexipages is more about being able to rapidly alter a single template with multiple RichContent areas (which could still be a site-wide used template, but it would be the whole template, not an included template component). 

Actually, more accurately the main difference is that flatblocks has more than a single commit to it and is more mature :)

[Tom Brander]

Thanks, that is very helpful, So it could also be said that flexipages can be used as a superset of flatblocks? That is not quite right though....