Currently pages have two flags for appearing in menus, "in navigation" and
"in footer". This doesn't really make sense, as there maybe more than two
types of menus on a site, and not necessarily a "footer" menu. The above
issue talks about adding a new flag for the left-hand menu, but again the
menus in use are going to be different for each site, and the flags should
reflect this.
I think the ideal setup would be one where we replaced the "in nav/footer"
flags with a multi-select field, that allowed users to choose multiple
selections from a list of menus, that the page is to appear in. The choices
in that field would map directly to each menu implemented on the site, and
then the checks could occur inside the actual page_menu template tag as to
whether the pages being passed to the menu template should be available.
The only thing I'm unsure about is how to populate the field with each type
of menu available for selection. I'd love for it to not require any
configuration or data. The menu templates are already conveniently bound to
a single template directory (pages/menus) so we could simply provide a list
of all the templates found in there for selection. The only problem with
this is that there'd be more templates in the selection field than those
that are actually in use. You might only implement a primary and a footer
menu, but there'd be at least half a dozen to choose from.
So I guess there could be a new setting that contained the names of the
menu templates actually in use. Then the new field would be populated by it.
Any thoughts on this change? Any gotchas? Any idea how to make it not
require configuration?
We can add a table called menu to hold all the menu types (left, right, footer,whatever you want) and the template to render it. With this aproach two menus can use the the same template, and you can create all the templates you want.
this table would be popullated by default with the main menu an the footer menu.
Currently pages have two flags for appearing in menus, "in navigation" and "in footer". This doesn't really make sense, as there maybe more than two types of menus on a site, and not necessarily a "footer" menu. The above issue talks about adding a new flag for the left-hand menu, but again the menus in use are going to be different for each site, and the flags should reflect this.
I think the ideal setup would be one where we replaced the "in nav/footer" flags with a multi-select field, that allowed users to choose multiple selections from a list of menus, that the page is to appear in. The choices in that field would map directly to each menu implemented on the site, and then the checks could occur inside the actual page_menu template tag as to whether the pages being passed to the menu template should be available.
The only thing I'm unsure about is how to populate the field with each type of menu available for selection. I'd love for it to not require any configuration or data. The menu templates are already conveniently bound to a single template directory (pages/menus) so we could simply provide a list of all the templates found in there for selection. The only problem with this is that there'd be more templates in the selection field than those that are actually in use. You might only implement a primary and a footer menu, but there'd be at least half a dozen to choose from.
So I guess there could be a new setting that contained the names of the menu templates actually in use. Then the new field would be populated by it.
Any thoughts on this change? Any gotchas? Any idea how to make it not require configuration?
So, if we convert the current menu flags to be a many-to-many foreign key multi-select to a menu model, the menu model would have:
- name
- template
- many-to-many list of pages so you can edit the page membership from the menu side rather than editing every single page.
- menu options:
-- drop down level?
-- group/roles required for menu to appear?
-- what to do if the user doesn't have privilege to see the page? for example, do you show a login_required page to an anonymous user? This behavior might have a default for that menu, but be overridden in the page-menu relation table (django calls them intermediary models).
Instead of an include, the menu would be a template tag? Filter tag so we can add options? This does open up some architectural choices in mezzanine. It would be great if there were a standard mezzanine way to deal with content plugins inside a page and one of the plugin types could be menus. Django-cms has the concept of placeholders in a page and everything else is a plugin (text fields, forms, menus, etc.). It seems that others are building this sub-page block functionality.
> We can add a table called menu to hold all the menu types (left, right, footer,whatever you want) and the template to render it. With this aproach two menus can use the the same template, and you can create all the templates you want.
> this table would be popullated by default with the main menu an the footer menu.
> What do you think?
> Stephen McDonald <st...@jupo.org> escribió:
> Just wanted to bring the conversation for this issue onto the mailing list:
> Currently pages have two flags for appearing in menus, "in navigation" and "in footer". This doesn't really make sense, as there maybe more than two types of menus on a site, and not necessarily a "footer" menu. The above issue talks about adding a new flag for the left-hand menu, but again the menus in use are going to be different for each site, and the flags should reflect this.
> I think the ideal setup would be one where we replaced the "in nav/footer" flags with a multi-select field, that allowed users to choose multiple selections from a list of menus, that the page is to appear in. The choices in that field would map directly to each menu implemented on the site, and then the checks could occur inside the actual page_menu template tag as to whether the pages being passed to the menu template should be available.
> The only thing I'm unsure about is how to populate the field with each type of menu available for selection. I'd love for it to not require any configuration or data. The menu templates are already conveniently bound to a single template directory (pages/menus) so we could simply provide a list of all the templates found in there for selection. The only problem with this is that there'd be more templates in the selection field than those that are actually in use. You might only implement a primary and a footer menu, but there'd be at least half a dozen to choose from.
> So I guess there could be a new setting that contained the names of the menu templates actually in use. Then the new field would be populated by it.
> Any thoughts on this change? Any gotchas? Any idea how to make it not require configuration?
Sorry about the delay in replying on this - I was hoping to answer it with
code but I just haven't found the time.
Firstly to answer the larger question of Mezzanine's architecture, as I
think that will add some perspective to the smaller question of menus.
So there's definitely two clear classes of design here. There's Mezzanine's
content types, which are Page model subclasses, with template types mapping
directly to each content type. Then there's the larger class if design -
one where pages are all of the same type, and built up by blocks fo content
individually represented by different records in databases, and selectable
templates per page. The corporate CMS project I work on during my day job
is of this latter type, and as I vaguely understand, is how Django CMS
works as well.
I don't think there's any question that the latter type is more advanced
and powerful. However I think the former design that Mezzanine implements
has a definite attractive simplicity to it. The relationships between Page
subclasses and templates are very easy to understand and think about, easy
to implement, and easy to extend. I think this design appeals to a
particular class of developers, and has worked well for Mezzanine for the
last couple of years.
I'm not arguing one class of design is better than the other. Both have
their pros and cons. I guess the point I'm trying to make is that
Mezzanine's elaning towards one end of this scale is a defining
characteristic of it, and that changing it would change a key aspect of it
that I think appeals to the developers that have adopted it.
The great thing is that for those wishing to create a more dynamic
architecture such as the latter of the two, separate tools like those you
listed have sprung up around Mezzanine, so the option is there. This is a
really good thing and I hope those projects developer further - but
ultimately I think Mezzanine's current architecture is a defining quality
of it, and for that reason will probably stay for the future.
So with all that in mind, as for the menus I think it would be best kept
simple to start with - a setting that defines the menu templates available,
and then each page can select from one or more of these as to whether it
should be included in that menu. The page_menu template tag can then
compare itself to this and choose whether the page should be included in
the menu, with this replacing the in_nav/in_fotter flags we currently have.
brian.sch...@nimbisservices.com> wrote:
> So, if we convert the current menu flags to be a many-to-many foreign key
> multi-select to a menu model, the menu model would have:
> - name
> - template
> - many-to-many list of pages so you can edit the page membership from the
> menu side rather than editing every single page.
> - menu options:
> -- drop down level?
> -- group/roles required for menu to appear?
> -- what to do if the user doesn't have privilege to see the page? for
> example, do you show a login_required page to an anonymous user? This
> behavior might have a default for that menu, but be overridden in the
> page-menu relation table (django calls them intermediary models).
> Instead of an include, the menu would be a template tag? Filter tag so we
> can add options? This does open up some architectural choices in
> mezzanine. It would be great if there were a standard mezzanine way to
> deal with content plugins inside a page and one of the plugin types could
> be menus. Django-cms has the concept of placeholders in a page and
> everything else is a plugin (text fields, forms, menus, etc.). It seems
> that others are building this sub-page block functionality.
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.sch...@nimbisservices.com
> ph: 443-274-6064 fx: 443-274-6060
> On Jun 23, 2012, at 3:32 PM, POKOLI I PUNTO wrote:
> We can add a table called menu to hold all the menu types (left, right,
> footer,whatever you want) and the template to render it. With this aproach
> two menus can use the the same template, and you can create all the
> templates you want.
> this table would be popullated by default with the main menu an the footer
> menu.
>> Currently pages have two flags for appearing in menus, "in navigation"
>> and "in footer". This doesn't really make sense, as there maybe more than
>> two types of menus on a site, and not necessarily a "footer" menu. The
>> above issue talks about adding a new flag for the left-hand menu, but again
>> the menus in use are going to be different for each site, and the flags
>> should reflect this.
>> I think the ideal setup would be one where we replaced the "in
>> nav/footer" flags with a multi-select field, that allowed users to choose
>> multiple selections from a list of menus, that the page is to appear in.
>> The choices in that field would map directly to each menu implemented on
>> the site, and then the checks could occur inside the actual page_menu
>> template tag as to whether the pages being passed to the menu template
>> should be available.
>> The only thing I'm unsure about is how to populate the field with each
>> type of menu available for selection. I'd love for it to not require any
>> configuration or data. The menu templates are already conveniently bound to
>> a single template directory (pages/menus) so we could simply provide a list
>> of all the templates found in there for selection. The only problem with
>> this is that there'd be more templates in the selection field than those
>> that are actually in use. You might only implement a primary and a footer
>> menu, but there'd be at least half a dozen to choose from.
>> So I guess there could be a new setting that contained the names of the
>> menu templates actually in use. Then the new field would be populated by it.
>> Any thoughts on this change? Any gotchas? Any idea how to make it not
>> require configuration?
It's good to understand the high-level design paradigm and I appreciate the thought that has gone into it. It makes sense. So, the menu membership would be a MultipleChoiceField configured through a setting? No need then, for a many-to-many relationship to another table. The menu templates would define any special behavior like drop-down level or group-based visibility and users could build their own. Would it be possible to have an admin view that is menu-centric, meaning not having to go edit every page to assign them to a new menu. Could be an action on pages view.
-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Jun 28, 2012, at 5:17 PM, Stephen McDonald wrote:
> Sorry about the delay in replying on this - I was hoping to answer it with code but I just haven't found the time.
> Firstly to answer the larger question of Mezzanine's architecture, as I think that will add some perspective to the smaller question of menus.
> So there's definitely two clear classes of design here. There's Mezzanine's content types, which are Page model subclasses, with template types mapping directly to each content type. Then there's the larger class if design - one where pages are all of the same type, and built up by blocks fo content individually represented by different records in databases, and selectable templates per page. The corporate CMS project I work on during my day job is of this latter type, and as I vaguely understand, is how Django CMS works as well.
> I don't think there's any question that the latter type is more advanced and powerful. However I think the former design that Mezzanine implements has a definite attractive simplicity to it. The relationships between Page subclasses and templates are very easy to understand and think about, easy to implement, and easy to extend. I think this design appeals to a particular class of developers, and has worked well for Mezzanine for the last couple of years.
> I'm not arguing one class of design is better than the other. Both have their pros and cons. I guess the point I'm trying to make is that Mezzanine's elaning towards one end of this scale is a defining characteristic of it, and that changing it would change a key aspect of it that I think appeals to the developers that have adopted it.
> The great thing is that for those wishing to create a more dynamic architecture such as the latter of the two, separate tools like those you listed have sprung up around Mezzanine, so the option is there. This is a really good thing and I hope those projects developer further - but ultimately I think Mezzanine's current architecture is a defining quality of it, and for that reason will probably stay for the future.
> So with all that in mind, as for the menus I think it would be best kept simple to start with - a setting that defines the menu templates available, and then each page can select from one or more of these as to whether it should be included in that menu. The page_menu template tag can then compare itself to this and choose whether the page should be included in the menu, with this replacing the in_nav/in_fotter flags we currently have.
> That's my take on the whole subject.
> On Sun, Jun 24, 2012 at 12:04 PM, Brian Schott <brian.sch...@nimbisservices.com> wrote:
> So, if we convert the current menu flags to be a many-to-many foreign key multi-select to a menu model, the menu model would have:
> - name
> - template
> - many-to-many list of pages so you can edit the page membership from the menu side rather than editing every single page.
> - menu options:
> -- drop down level?
> -- group/roles required for menu to appear?
> -- what to do if the user doesn't have privilege to see the page? for example, do you show a login_required page to an anonymous user? This behavior might have a default for that menu, but be overridden in the page-menu relation table (django calls them intermediary models).
> Instead of an include, the menu would be a template tag? Filter tag so we can add options? This does open up some architectural choices in mezzanine. It would be great if there were a standard mezzanine way to deal with content plugins inside a page and one of the plugin types could be menus. Django-cms has the concept of placeholders in a page and everything else is a plugin (text fields, forms, menus, etc.). It seems that others are building this sub-page block functionality.
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.sch...@nimbisservices.com
> ph: 443-274-6064 fx: 443-274-6060
> On Jun 23, 2012, at 3:32 PM, POKOLI I PUNTO wrote:
>> We can add a table called menu to hold all the menu types (left, right, footer,whatever you want) and the template to render it. With this aproach two menus can use the the same template, and you can create all the templates you want.
>> this table would be popullated by default with the main menu an the footer menu.
>> What do you think?
>> Stephen McDonald <st...@jupo.org> escribió:
>> Just wanted to bring the conversation for this issue onto the mailing list:
>> Currently pages have two flags for appearing in menus, "in navigation" and "in footer". This doesn't really make sense, as there maybe more than two types of menus on a site, and not necessarily a "footer" menu. The above issue talks about adding a new flag for the left-hand menu, but again the menus in use are going to be different for each site, and the flags should reflect this.
>> I think the ideal setup would be one where we replaced the "in nav/footer" flags with a multi-select field, that allowed users to choose multiple selections from a list of menus, that the page is to appear in. The choices in that field would map directly to each menu implemented on the site, and then the checks could occur inside the actual page_menu template tag as to whether the pages being passed to the menu template should be available.
>> The only thing I'm unsure about is how to populate the field with each type of menu available for selection. I'd love for it to not require any configuration or data. The menu templates are already conveniently bound to a single template directory (pages/menus) so we could simply provide a list of all the templates found in there for selection. The only problem with this is that there'd be more templates in the selection field than those that are actually in use. You might only implement a primary and a footer menu, but there'd be at least half a dozen to choose from.
>> So I guess there could be a new setting that contained the names of the menu templates actually in use. Then the new field would be populated by it.
>> Any thoughts on this change? Any gotchas? Any idea how to make it not require configuration?
brian.sch...@nimbisservices.com> wrote:
> It's good to understand the high-level design paradigm and I appreciate
> the thought that has gone into it. It makes sense. So, the menu
> membership would be a MultipleChoiceField configured through a setting? No
> need then, for a many-to-many relationship to another table. The menu
> templates would define any special behavior like drop-down level or
> group-based visibility and users could build their own.
That's the plan - I started working on it this morning, might have
something to show tomorrow.
> Would it be possible to have an admin view that is menu-centric, meaning
> not having to go edit every page to assign them to a new menu. Could be an
> action on pages view.
Hadn't thought of that but I think it's a great idea.
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.sch...@nimbisservices.com
> ph: 443-274-6064 fx: 443-274-6060
> On Jun 28, 2012, at 5:17 PM, Stephen McDonald wrote:
> Sorry about the delay in replying on this - I was hoping to answer it with
> code but I just haven't found the time.
> Firstly to answer the larger question of Mezzanine's architecture, as I
> think that will add some perspective to the smaller question of menus.
> So there's definitely two clear classes of design here. There's
> Mezzanine's content types, which are Page model subclasses, with template
> types mapping directly to each content type. Then there's the larger class
> if design - one where pages are all of the same type, and built up by
> blocks fo content individually represented by different records in
> databases, and selectable templates per page. The corporate CMS project I
> work on during my day job is of this latter type, and as I vaguely
> understand, is how Django CMS works as well.
> I don't think there's any question that the latter type is more advanced
> and powerful. However I think the former design that Mezzanine implements
> has a definite attractive simplicity to it. The relationships between Page
> subclasses and templates are very easy to understand and think about, easy
> to implement, and easy to extend. I think this design appeals to a
> particular class of developers, and has worked well for Mezzanine for the
> last couple of years.
> I'm not arguing one class of design is better than the other. Both have
> their pros and cons. I guess the point I'm trying to make is that
> Mezzanine's elaning towards one end of this scale is a defining
> characteristic of it, and that changing it would change a key aspect of it
> that I think appeals to the developers that have adopted it.
> The great thing is that for those wishing to create a more dynamic
> architecture such as the latter of the two, separate tools like those you
> listed have sprung up around Mezzanine, so the option is there. This is a
> really good thing and I hope those projects developer further - but
> ultimately I think Mezzanine's current architecture is a defining quality
> of it, and for that reason will probably stay for the future.
> So with all that in mind, as for the menus I think it would be best kept
> simple to start with - a setting that defines the menu templates available,
> and then each page can select from one or more of these as to whether it
> should be included in that menu. The page_menu template tag can then
> compare itself to this and choose whether the page should be included in
> the menu, with this replacing the in_nav/in_fotter flags we currently have.
> That's my take on the whole subject.
> On Sun, Jun 24, 2012 at 12:04 PM, Brian Schott <
> brian.sch...@nimbisservices.com> wrote:
>> So, if we convert the current menu flags to be a many-to-many foreign key
>> multi-select to a menu model, the menu model would have:
>> - name
>> - template
>> - many-to-many list of pages so you can edit the page membership from the
>> menu side rather than editing every single page.
>> - menu options:
>> -- drop down level?
>> -- group/roles required for menu to appear?
>> -- what to do if the user doesn't have privilege to see the page? for
>> example, do you show a login_required page to an anonymous user? This
>> behavior might have a default for that menu, but be overridden in the
>> page-menu relation table (django calls them intermediary models).
>> Instead of an include, the menu would be a template tag? Filter tag so
>> we can add options? This does open up some architectural choices in
>> mezzanine. It would be great if there were a standard mezzanine way to
>> deal with content plugins inside a page and one of the plugin types could
>> be menus. Django-cms has the concept of placeholders in a page and
>> everything else is a plugin (text fields, forms, menus, etc.). It seems
>> that others are building this sub-page block functionality.
>> -------------------------------------------------
>> Brian Schott, CTO
>> Nimbis Services, Inc.
>> brian.sch...@nimbisservices.com
>> ph: 443-274-6064 fx: 443-274-6060
>> On Jun 23, 2012, at 3:32 PM, POKOLI I PUNTO wrote:
>> We can add a table called menu to hold all the menu types (left, right,
>> footer,whatever you want) and the template to render it. With this aproach
>> two menus can use the the same template, and you can create all the
>> templates you want.
>> this table would be popullated by default with the main menu an the
>> footer menu.
>>> Currently pages have two flags for appearing in menus, "in navigation"
>>> and "in footer". This doesn't really make sense, as there maybe more than
>>> two types of menus on a site, and not necessarily a "footer" menu. The
>>> above issue talks about adding a new flag for the left-hand menu, but again
>>> the menus in use are going to be different for each site, and the flags
>>> should reflect this.
>>> I think the ideal setup would be one where we replaced the "in
>>> nav/footer" flags with a multi-select field, that allowed users to choose
>>> multiple selections from a list of menus, that the page is to appear in.
>>> The choices in that field would map directly to each menu implemented on
>>> the site, and then the checks could occur inside the actual page_menu
>>> template tag as to whether the pages being passed to the menu template
>>> should be available.
>>> The only thing I'm unsure about is how to populate the field with each
>>> type of menu available for selection. I'd love for it to not require any
>>> configuration or data. The menu templates are already conveniently bound to
>>> a single template directory (pages/menus) so we could simply provide a list
>>> of all the templates found in there for selection. The only problem with
>>> this is that there'd be more templates in the selection field than those
>>> that are actually in use. You might only implement a primary and a footer
>>> menu, but there'd be at least half a dozen to choose from.
>>> So I guess there could be a new setting that contained the names of the
>>> menu templates actually in use. Then the new field would be populated by it.
>>> Any thoughts on this change? Any gotchas? Any idea how to make it not
>>> require configuration?
The "in_navigation" and "in_footer" fields are gone and replace with a new
field "in_menus", which contains a comma-separated list of menu IDs that
the page belongs to. The menu IDs are defined in the setting
PAGE_MENU_TEMPLATES which looks like this:
So you can define the exact menu templates available in your project.
In the menu templates, page objects now have an attribute "in_menu", to use
in place of the removed fields, and the variables "page_branch_in_footer"
and "page_branch_in_navigation" are replaced with "page_branch_in_menu"
(the old attributes and variables remain for now as best as possible, for
backward compatibility with templates, take a look at the above commit to
see their behaviour).
A couple of notes around the behaviour of this inside the "page_menu"
template tag, which I'm going to add with some new docs for the way menus
work:
- Just as the old flags behaved, the new "in_menus" field doesn't actually
filter pages from a menu - it's up to the menu template to check
"page.in_menu" itself.
- If a menu template isn't defined in PAGE_MENU_TEMPLATES, "page.in_menu"
will always be True. Think of the "in_menus" field as controlling what
menus the page *won't* be in, by unchecking them.
- The default selection for the "in_menus" field with a new page is all
menu templates, you can change the default selection by setting a sequence
of menu IDs in the new PAGE_MENU_TEMPLATES_DEFAULT setting.
On Sat, Jun 23, 2012 at 4:59 PM, Stephen McDonald <st...@jupo.org> wrote:
> Just wanted to bring the conversation for this issue onto the mailing list:
> Currently pages have two flags for appearing in menus, "in navigation" and
> "in footer". This doesn't really make sense, as there maybe more than two
> types of menus on a site, and not necessarily a "footer" menu. The above
> issue talks about adding a new flag for the left-hand menu, but again the
> menus in use are going to be different for each site, and the flags should
> reflect this.
> I think the ideal setup would be one where we replaced the "in nav/footer"
> flags with a multi-select field, that allowed users to choose multiple
> selections from a list of menus, that the page is to appear in. The choices
> in that field would map directly to each menu implemented on the site, and
> then the checks could occur inside the actual page_menu template tag as to
> whether the pages being passed to the menu template should be available.
> The only thing I'm unsure about is how to populate the field with each
> type of menu available for selection. I'd love for it to not require any
> configuration or data. The menu templates are already conveniently bound to
> a single template directory (pages/menus) so we could simply provide a list
> of all the templates found in there for selection. The only problem with
> this is that there'd be more templates in the selection field than those
> that are actually in use. You might only implement a primary and a footer
> menu, but there'd be at least half a dozen to choose from.
> So I guess there could be a new setting that contained the names of the
> menu templates actually in use. Then the new field would be populated by it.
> Any thoughts on this change? Any gotchas? Any idea how to make it not
> require configuration?
> The "in_navigation" and "in_footer" fields are gone and replace with a new
> field "in_menus", which contains a comma-separated list of menu IDs that
> the page belongs to. The menu IDs are defined in the setting
> PAGE_MENU_TEMPLATES which looks like this:
> So you can define the exact menu templates available in your project.
> In the menu templates, page objects now have an attribute "in_menu", to
> use in place of the removed fields, and the variables
> "page_branch_in_footer" and "page_branch_in_navigation" are replaced with
> "page_branch_in_menu" (the old attributes and variables remain for now as
> best as possible, for backward compatibility with templates, take a look at
> the above commit to see their behaviour).
Linked commit in last email was missing a file, namely the changes to the
page_menu template tag, which contains the backward compatibility I
mentioned. Here it is:
> A couple of notes around the behaviour of this inside the "page_menu"
> template tag, which I'm going to add with some new docs for the way menus
> work:
> - Just as the old flags behaved, the new "in_menus" field doesn't actually
> filter pages from a menu - it's up to the menu template to check
> "page.in_menu" itself.
> - If a menu template isn't defined in PAGE_MENU_TEMPLATES, "page.in_menu"
> will always be True. Think of the "in_menus" field as controlling what
> menus the page *won't* be in, by unchecking them.
> - The default selection for the "in_menus" field with a new page is all
> menu templates, you can change the default selection by setting a sequence
> of menu IDs in the new PAGE_MENU_TEMPLATES_DEFAULT setting.
> On Sat, Jun 23, 2012 at 4:59 PM, Stephen McDonald <st...@jupo.org> wrote:
>> Just wanted to bring the conversation for this issue onto the mailing
>> list:
>> Currently pages have two flags for appearing in menus, "in navigation"
>> and "in footer". This doesn't really make sense, as there maybe more than
>> two types of menus on a site, and not necessarily a "footer" menu. The
>> above issue talks about adding a new flag for the left-hand menu, but again
>> the menus in use are going to be different for each site, and the flags
>> should reflect this.
>> I think the ideal setup would be one where we replaced the "in
>> nav/footer" flags with a multi-select field, that allowed users to choose
>> multiple selections from a list of menus, that the page is to appear in.
>> The choices in that field would map directly to each menu implemented on
>> the site, and then the checks could occur inside the actual page_menu
>> template tag as to whether the pages being passed to the menu template
>> should be available.
>> The only thing I'm unsure about is how to populate the field with each
>> type of menu available for selection. I'd love for it to not require any
>> configuration or data. The menu templates are already conveniently bound to
>> a single template directory (pages/menus) so we could simply provide a list
>> of all the templates found in there for selection. The only problem with
>> this is that there'd be more templates in the selection field than those
>> that are actually in use. You might only implement a primary and a footer
>> menu, but there'd be at least half a dozen to choose from.
>> So I guess there could be a new setting that contained the names of the
>> menu templates actually in use. Then the new field would be populated by it.
>> Any thoughts on this change? Any gotchas? Any idea how to make it not
>> require configuration?
> The "in_navigation" and "in_footer" fields are gone and replace with a new field "in_menus", which contains a comma-separated list of menu IDs that the page belongs to. The menu IDs are defined in the setting PAGE_MENU_TEMPLATES which looks like this:
> So you can define the exact menu templates available in your project.
> In the menu templates, page objects now have an attribute "in_menu", to use in place of the removed fields, and the variables "page_branch_in_footer" and "page_branch_in_navigation" are replaced with "page_branch_in_menu" (the old attributes and variables remain for now as best as possible, for backward compatibility with templates, take a look at the above commit to see their behaviour).
> Linked commit in last email was missing a file, namely the changes to the page_menu template tag, which contains the backward compatibility I mentioned. Here it is:
> A couple of notes around the behaviour of this inside the "page_menu" template tag, which I'm going to add with some new docs for the way menus work:
> - Just as the old flags behaved, the new "in_menus" field doesn't actually filter pages from a menu - it's up to the menu template to check "page.in_menu" itself.
> - If a menu template isn't defined in PAGE_MENU_TEMPLATES, "page.in_menu" will always be True. Think of the "in_menus" field as controlling what menus the page *won't* be in, by unchecking them.
> - The default selection for the "in_menus" field with a new page is all menu templates, you can change the default selection by setting a sequence of menu IDs in the new PAGE_MENU_TEMPLATES_DEFAULT setting.
> On Sat, Jun 23, 2012 at 4:59 PM, Stephen McDonald <st...@jupo.org> wrote:
> Just wanted to bring the conversation for this issue onto the mailing list:
> Currently pages have two flags for appearing in menus, "in navigation" and "in footer". This doesn't really make sense, as there maybe more than two types of menus on a site, and not necessarily a "footer" menu. The above issue talks about adding a new flag for the left-hand menu, but again the menus in use are going to be different for each site, and the flags should reflect this.
> I think the ideal setup would be one where we replaced the "in nav/footer" flags with a multi-select field, that allowed users to choose multiple selections from a list of menus, that the page is to appear in. The choices in that field would map directly to each menu implemented on the site, and then the checks could occur inside the actual page_menu template tag as to whether the pages being passed to the menu template should be available.
> The only thing I'm unsure about is how to populate the field with each type of menu available for selection. I'd love for it to not require any configuration or data. The menu templates are already conveniently bound to a single template directory (pages/menus) so we could simply provide a list of all the templates found in there for selection. The only problem with this is that there'd be more templates in the selection field than those that are actually in use. You might only implement a primary and a footer menu, but there'd be at least half a dozen to choose from.
> So I guess there could be a new setting that contained the names of the menu templates actually in use. Then the new field would be populated by it.
> Any thoughts on this change? Any gotchas? Any idea how to make it not require configuration?
> The "in_navigation" and "in_footer" fields are gone and replace with a new
> field "in_menus", which contains a comma-separated list of menu IDs that
> the page belongs to. The menu IDs are defined in the setting
> PAGE_MENU_TEMPLATES which looks like this:
> So you can define the exact menu templates available in your project.
> In the menu templates, page objects now have an attribute "in_menu", to
> use in place of the removed fields, and the variables
> "page_branch_in_footer" and "page_branch_in_navigation" are replaced with
> "page_branch_in_menu" (the old attributes and variables remain for now as
> best as possible, for backward compatibility with templates, take a look at
> the above commit to see their behaviour).
> A couple of notes around the behaviour of this inside the "page_menu"
> template tag, which I'm going to add with some new docs for the way menus
> work:
> - Just as the old flags behaved, the new "in_menus" field doesn't actually
> filter pages from a menu - it's up to the menu template to check
> "page.in_menu" itself.
> - If a menu template isn't defined in PAGE_MENU_TEMPLATES, "page.in_menu"
> will always be True. Think of the "in_menus" field as controlling what
> menus the page *won't* be in, by unchecking them.
> - The default selection for the "in_menus" field with a new page is all
> menu templates, you can change the default selection by setting a sequence
> of menu IDs in the new PAGE_MENU_TEMPLATES_DEFAULT setting.
> On Sat, Jun 23, 2012 at 4:59 PM, Stephen McDonald <st...@jupo.org> wrote:
>> Just wanted to bring the conversation for this issue onto the mailing
>> list:
>> Currently pages have two flags for appearing in menus, "in navigation"
>> and "in footer". This doesn't really make sense, as there maybe more than
>> two types of menus on a site, and not necessarily a "footer" menu. The
>> above issue talks about adding a new flag for the left-hand menu, but again
>> the menus in use are going to be different for each site, and the flags
>> should reflect this.
>> I think the ideal setup would be one where we replaced the "in
>> nav/footer" flags with a multi-select field, that allowed users to choose
>> multiple selections from a list of menus, that the page is to appear in.
>> The choices in that field would map directly to each menu implemented on
>> the site, and then the checks could occur inside the actual page_menu
>> template tag as to whether the pages being passed to the menu template
>> should be available.
>> The only thing I'm unsure about is how to populate the field with each
>> type of menu available for selection. I'd love for it to not require any
>> configuration or data. The menu templates are already conveniently bound to
>> a single template directory (pages/menus) so we could simply provide a list
>> of all the templates found in there for selection. The only problem with
>> this is that there'd be more templates in the selection field than those
>> that are actually in use. You might only implement a primary and a footer
>> menu, but there'd be at least half a dozen to choose from.
>> So I guess there could be a new setting that contained the names of the
>> menu templates actually in use. Then the new field would be populated by it.
>> Any thoughts on this change? Any gotchas? Any idea how to make it not
>> require configuration?
>> The "in_navigation" and "in_footer" fields are gone and replace with a >> new field "in_menus", which contains a comma-separated list of menu IDs >> that the page belongs to. The menu IDs are defined in the setting >> PAGE_MENU_TEMPLATES which looks like this:
>> So you can define the exact menu templates available in your project.
>> In the menu templates, page objects now have an attribute "in_menu", to >> use in place of the removed fields, and the variables >> "page_branch_in_footer" and "page_branch_in_navigation" are replaced with >> "page_branch_in_menu" (the old attributes and variables remain for now as >> best as possible, for backward compatibility with templates, take a look at >> the above commit to see their behaviour).
>> A couple of notes around the behaviour of this inside the "page_menu" >> template tag, which I'm going to add with some new docs for the way menus >> work:
>> - Just as the old flags behaved, the new "in_menus" field doesn't >> actually filter pages from a menu - it's up to the menu template to check >> "page.in_menu" itself. >> - If a menu template isn't defined in PAGE_MENU_TEMPLATES, "page.in_menu" >> will always be True. Think of the "in_menus" field as controlling what >> menus the page *won't* be in, by unchecking them. >> - The default selection for the "in_menus" field with a new page is all >> menu templates, you can change the default selection by setting a sequence >> of menu IDs in the new PAGE_MENU_TEMPLATES_DEFAULT setting.
>> On Sat, Jun 23, 2012 at 4:59 PM, Stephen McDonald <st...@jupo.org> wrote:
>>> Just wanted to bring the conversation for this issue onto the mailing >>> list:
>>> Currently pages have two flags for appearing in menus, "in navigation" >>> and "in footer". This doesn't really make sense, as there maybe more than >>> two types of menus on a site, and not necessarily a "footer" menu. The >>> above issue talks about adding a new flag for the left-hand menu, but again >>> the menus in use are going to be different for each site, and the flags >>> should reflect this.
>>> I think the ideal setup would be one where we replaced the "in >>> nav/footer" flags with a multi-select field, that allowed users to choose >>> multiple selections from a list of menus, that the page is to appear in. >>> The choices in that field would map directly to each menu implemented on >>> the site, and then the checks could occur inside the actual page_menu >>> template tag as to whether the pages being passed to the menu template >>> should be available.
>>> The only thing I'm unsure about is how to populate the field with each >>> type of menu available for selection. I'd love for it to not require any >>> configuration or data. The menu templates are already conveniently bound to >>> a single template directory (pages/menus) so we could simply provide a list >>> of all the templates found in there for selection. The only problem with >>> this is that there'd be more templates in the selection field than those >>> that are actually in use. You might only implement a primary and a footer >>> menu, but there'd be at least half a dozen to choose from.
>>> So I guess there could be a new setting that contained the names of the >>> menu templates actually in use. Then the new field would be populated by it.
>>> Any thoughts on this change? Any gotchas? Any idea how to make it not >>> require configuration?
> The "in_navigation" and "in_footer" fields are gone and replace with a new field "in_menus", which contains a comma-separated list of menu IDs that the page belongs to. The menu IDs are defined in the setting PAGE_MENU_TEMPLATES which looks like this:
> So you can define the exact menu templates available in your project.
> In the menu templates, page objects now have an attribute "in_menu", to use in place of the removed fields, and the variables "page_branch_in_footer" and "page_branch_in_navigation" are replaced with "page_branch_in_menu" (the old attributes and variables remain for now as best as possible, for backward compatibility with templates, take a look at the above commit to see their behaviour).
> A couple of notes around the behaviour of this inside the "page_menu" template tag, which I'm going to add with some new docs for the way menus work:
> - Just as the old flags behaved, the new "in_menus" field doesn't actually filter pages from a menu - it's up to the menu template to check "page.in_menu" itself.
> - If a menu template isn't defined in PAGE_MENU_TEMPLATES, "page.in_menu" will always be True. Think of the "in_menus" field as controlling what menus the page *won't* be in, by unchecking them.
> - The default selection for the "in_menus" field with a new page is all menu templates, you can change the default selection by setting a sequence of menu IDs in the new PAGE_MENU_TEMPLATES_DEFAULT setting.
> On Sat, Jun 23, 2012 at 4:59 PM, Stephen McDonald <st...@jupo.org> wrote:
> Just wanted to bring the conversation for this issue onto the mailing list:
> Currently pages have two flags for appearing in menus, "in navigation" and "in footer". This doesn't really make sense, as there maybe more than two types of menus on a site, and not necessarily a "footer" menu. The above issue talks about adding a new flag for the left-hand menu, but again the menus in use are going to be different for each site, and the flags should reflect this.
> I think the ideal setup would be one where we replaced the "in nav/footer" flags with a multi-select field, that allowed users to choose multiple selections from a list of menus, that the page is to appear in. The choices in that field would map directly to each menu implemented on the site, and then the checks could occur inside the actual page_menu template tag as to whether the pages being passed to the menu template should be available.
> The only thing I'm unsure about is how to populate the field with each type of menu available for selection. I'd love for it to not require any configuration or data. The menu templates are already conveniently bound to a single template directory (pages/menus) so we could simply provide a list of all the templates found in there for selection. The only problem with this is that there'd be more templates in the selection field than those that are actually in use. You might only implement a primary and a footer menu, but there'd be at least half a dozen to choose from.
> So I guess there could be a new setting that contained the names of the menu templates actually in use. Then the new field would be populated by it.
> Any thoughts on this change? Any gotchas? Any idea how to make it not require configuration?
Just traced this down to a recent change where a new "Link" page type was
added. What it meant is that we needed to change the way urls for page
objects were used in templates. Here's the whole commit, including the
changes to the menu templates that need to happen:
>>> The "in_navigation" and "in_footer" fields are gone and replace with a
>>> new field "in_menus", which contains a comma-separated list of menu IDs
>>> that the page belongs to. The menu IDs are defined in the setting
>>> PAGE_MENU_TEMPLATES which looks like this:
>>> So you can define the exact menu templates available in your project.
>>> In the menu templates, page objects now have an attribute "in_menu", to
>>> use in place of the removed fields, and the variables
>>> "page_branch_in_footer" and "page_branch_in_navigation" are replaced with
>>> "page_branch_in_menu" (the old attributes and variables remain for now as
>>> best as possible, for backward compatibility with templates, take a look at
>>> the above commit to see their behaviour).
>>> A couple of notes around the behaviour of this inside the "page_menu"
>>> template tag, which I'm going to add with some new docs for the way menus
>>> work:
>>> - Just as the old flags behaved, the new "in_menus" field doesn't
>>> actually filter pages from a menu - it's up to the menu template to check
>>> "page.in_menu" itself.
>>> - If a menu template isn't defined in PAGE_MENU_TEMPLATES,
>>> "page.in_menu" will always be True. Think of the "in_menus" field as
>>> controlling what menus the page *won't* be in, by unchecking them.
>>> - The default selection for the "in_menus" field with a new page is all
>>> menu templates, you can change the default selection by setting a sequence
>>> of menu IDs in the new PAGE_MENU_TEMPLATES_**DEFAULT setting.
>>> On Sat, Jun 23, 2012 at 4:59 PM, Stephen McDonald <st...@jupo.org>wrote:
>>>> Just wanted to bring the conversation for this issue onto the mailing
>>>> list:
>>>> Currently pages have two flags for appearing in menus, "in navigation"
>>>> and "in footer". This doesn't really make sense, as there maybe more than
>>>> two types of menus on a site, and not necessarily a "footer" menu. The
>>>> above issue talks about adding a new flag for the left-hand menu, but again
>>>> the menus in use are going to be different for each site, and the flags
>>>> should reflect this.
>>>> I think the ideal setup would be one where we replaced the "in
>>>> nav/footer" flags with a multi-select field, that allowed users to choose
>>>> multiple selections from a list of menus, that the page is to appear in.
>>>> The choices in that field would map directly to each menu implemented on
>>>> the site, and then the checks could occur inside the actual page_menu
>>>> template tag as to whether the pages being passed to the menu template
>>>> should be available.
>>>> The only thing I'm unsure about is how to populate the field with each
>>>> type of menu available for selection. I'd love for it to not require any
>>>> configuration or data. The menu templates are already conveniently bound to
>>>> a single template directory (pages/menus) so we could simply provide a list
>>>> of all the templates found in there for selection. The only problem with
>>>> this is that there'd be more templates in the selection field than those
>>>> that are actually in use. You might only implement a primary and a footer
>>>> menu, but there'd be at least half a dozen to choose from.
>>>> So I guess there could be a new setting that contained the names of the
>>>> menu templates actually in use. Then the new field would be populated by it.
>>>> Any thoughts on this change? Any gotchas? Any idea how to make it not
>>>> require configuration?
