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.
On Thursday, September 27, 2012 6:04:55 PM UTC+10, Gour wrote:
> 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:
> 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.
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 :)
> 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 :)
On Wed, Nov 28, 2012 at 12:19 AM, Stephen McDonald <st...@jupo.org> wrote:
> On Wed, Nov 28, 2012 at 3:40 PM, Eduardo Rivas <jerivasmel...@gmail.com>wrote:
>> 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 :)
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.
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?
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?"
On Thu, Nov 29, 2012 at 7:50 AM, Ahmad Khayyat <akhay...@gmail.com> wrote:
> 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.
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.
On Fri, Nov 30, 2012 at 4:01 AM, Ahmad Khayyat <akhay...@gmail.com> wrote:
> 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.
Great idea - that actually seems like the best place that text would go
verbatim.
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.
On Friday, November 30, 2012 4:07:42 AM UTC+11, Stephen McDonald wrote:
> On Fri, Nov 30, 2012 at 4:01 AM, Ahmad Khayyat <akha...@gmail.com<javascript:> > > wrote:
>> On Thu, Nov 29, 2012 at 11:57 AM, Stephen McDonald <st...@jupo.org<javascript:> >> > 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.
> Great idea - that actually seems like the best place that text would go > verbatim.
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?
> 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
> On Friday, November 30, 2012 4:07:42 AM UTC+11, Stephen McDonald wrote:
>> On Fri, Nov 30, 2012 at 4:01 AM, Ahmad Khayyat <akha...@gmail.com> wrote:
>>> 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.
>> Great idea - that actually seems like the best place that text would go >> verbatim.
> 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
> On Friday, November 30, 2012 4:07:42 AM UTC+11, Stephen McDonald wrote:
>> On Fri, Nov 30, 2012 at 4:01 AM, Ahmad Khayyat <akha...@gmail.com> wrote:
>> 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.
>> Great idea - that actually seems like the best place that text would go
>> verbatim.
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 :)
On Thursday, December 13, 2012 3:34:34 PM UTC+11, Tom Brander wrote:
> 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?
> On Wednesday, December 12, 2012 5:44:30 PM UTC-6, Peter Davis wrote:
>> Hi,
>> Spurred on by the discussion in this thread I made a mezzanine extension >> called mezzanine-flexipage<https://github.com/mrmagooey/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
>> On Friday, November 30, 2012 4:07:42 AM UTC+11, Stephen McDonald wrote:
>>> On Fri, Nov 30, 2012 at 4:01 AM, Ahmad Khayyat <akha...@gmail.com>wrote:
>>>> 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.
>>> Great idea - that actually seems like the best place that text would go >>> verbatim.
On Thursday, December 13, 2012 5:15:02 PM UTC-6, Peter Davis wrote:
> 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 :)
> On Thursday, December 13, 2012 3:34:34 PM UTC+11, Tom Brander wrote:
>> 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?
>> On Wednesday, December 12, 2012 5:44:30 PM UTC-6, Peter Davis wrote:
>>> Hi,
>>> Spurred on by the discussion in this thread I made a mezzanine extension >>> called mezzanine-flexipage<https://github.com/mrmagooey/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
>>> On Friday, November 30, 2012 4:07:42 AM UTC+11, Stephen McDonald wrote:
>>>> On Fri, Nov 30, 2012 at 4:01 AM, Ahmad Khayyat <akha...@gmail.com>wrote:
>>>>> 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.
>>>> Great idea - that actually seems like the best place that text would go >>>> verbatim.
mezzanine-flexipage is awesome. I was able to get it up and working quickly and it is really going to help me move quickly on a project I'm doing. Thank you!
> 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
> On Friday, November 30, 2012 4:07:42 AM UTC+11, Stephen McDonald wrote:
>> On Fri, Nov 30, 2012 at 4:01 AM, Ahmad Khayyat <akha...@gmail.com> wrote:
>>> 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.
>> Great idea - that actually seems like the best place that text would go >> verbatim.
