Making customization of OSCAR_DASHBOARD_NAVIGATION easy
168 views
Skip to first unread message
Markus Bertheau
Nov 25, 2013, 11:26:02 AM11/25/13
to django...@googlegroups.com
Hi,
in our Oscar installation we need to rename and reorder some of the items in OSCAR_DASHBOARD_NAVIGATION. Currently this isn't possible without copying and modifying the whole pretty large structure. Duplicating it has the usual drawbacks. So we were thinking about a way to model OSCAR_DASHBOARD_NAVIGATION that makes this kind of customization easier.
One approach we tried is in https://github.com/mbertheau/django-oscar/commit/5f4deace1f800e9e7049952a809574c44da94431. However I'm not satisfied with how that turned out. The position key is obviously necessary to support reordering, but it's very cumbersome and sometimes problematic: what position do you use when you want to insert an item into the dashboard navigation between positions 0 and 1? 1.5 is certainly possible but doesn't feel right. I prefer using a python list to specify the order of items in the navigation. The second thing that makes this solution not feel right with me is the need for an update_dict_recursively function. That feels too complicated.
Then I thought about an array that has just the url_names for leaves maybe like this:
OSCAR_NAV_CATALOGUE = (_('Catalogue'), 'icon-sitemap',
['dashboard:catalogue-product-list', 'dashboard:catalogue-category-list', ...]
OSCAR_NAV = ['dashboard:index', OSCAR_NAV_CATALOGUE, ...]
and have the label, icon and access_fn information somehow stored with the urls, or maybe with the associated views. However what I still don't like about that approach is that the icons and labels are specified in different places for leaves and nodes of the nav tree. We could have leaves in the settings as well:
OSCAR_NAV_PRODUCTS = (_('Products'), 'dashboard:catalogue-product-list'))
...
OSCAR_NAV_CATALOGUE = (_('Catalogue'), 'icon-sitemap',
[OSCAR_NAV_PRODUCTS, OSCAR_NAV_CATEGORIES, ...]
however if I want to replace or rename e.g. catalogue -> ranges, I have to specify not only OSCAR_NAV_RANGES in my settings, but also OSACR_NAV_CATALOGUE and OSCAR_NAV in order for the changes to be picked up. Also the setting names get very very long: OSCAR_DASHBOARD_NAVIGATION_CATALOGUE, which is another reason why I wanted to put icon and label information with the url or the associated view, but it doesn't help with nodes.
Any other ideas?
Thanks :)
Markus
Maik Hoepfel
Nov 29, 2013, 5:57:51 AM11/29/13
to django...@googlegroups.com
Hi Markus,
I'm happy to consider improvements to how the navigation is handled. But
frankly, right now I don't see a big issue with it. Your main concern is
that the current solution is quite verbose?
For my Oscar project, I copied defaults.py into my settings folder
anyway and named it shop_settings. That gets included in my base
settings file. I find that a workable solution, and it ensures I don't
miss any Oscar settings.
Regards,
Maik
> --
> https://github.com/tangentlabs/django-oscar
> http://django-oscar.readthedocs.org/en/latest/
> https://twitter.com/django_oscar
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-oscar...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-oscar.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-oscar/dad7973b-86e4-4b77-8f17-2e2d89b518d1%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
I'm happy to consider improvements to how the navigation is handled. But
frankly, right now I don't see a big issue with it. Your main concern is
that the current solution is quite verbose?
For my Oscar project, I copied defaults.py into my settings folder
anyway and named it shop_settings. That gets included in my base
settings file. I find that a workable solution, and it ensures I don't
miss any Oscar settings.
Regards,
Maik
> https://github.com/tangentlabs/django-oscar
> http://django-oscar.readthedocs.org/en/latest/
> https://twitter.com/django_oscar
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-oscar...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-oscar.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-oscar/dad7973b-86e4-4b77-8f17-2e2d89b518d1%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Markus Bertheau
Nov 29, 2013, 6:34:20 AM11/29/13
to django...@googlegroups.com
Hi Maik,
I just ported an (incomplete) app from 0.5 to master a few weeks ago and with that experience in mind I try to reduce code duplication during implementation of oscar for our current project. The fact that it's verbose is not the problem, but that I can't change it sensibly without copying it whole, even if I want to change just one small thing (like the label of a dashbord navigation item). Then when we update to oscar-0.7 we have a manual three-way-merge on our hands for each.
Thanks :)
Markus
an email to django-oscar+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/django-oscar.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-oscar/dad7973b-86e4-4b77-8f17-2e2d89b518d1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--- You received this message because you are subscribed to a topic in the Google Groups "django-oscar" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-oscar/Gh18GXmoDrw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-oscar+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-oscar/5298732F.9000702%40tangentsnowball.com.
Maik Hoepfel
Nov 29, 2013, 6:52:36 AM11/29/13
to django...@googlegroups.com
Hi Markus,
okay, I see the problem. My assumption is that every shop in production
will use a custom dashboard navigation, so I haven't been too concerned
about it. And changes to DASHBOARD_NAVIGATION should be minimal between
releases. The likely scenario is that new navigation items will get
added. And in that case, I think forcing a decision to include or
exclude during the upgrade is a reasonable thing to do.
Do you think adding changes to DASHBOARD_NAVIGATION to the release notes
is a decent solution for now?
Regards,
Maik
On 29/11/13 11:34, Markus Bertheau wrote:
> Hi Maik,
>
> I just ported an (incomplete) app from 0.5 to master a few weeks ago and
> with that experience in mind I try to reduce code duplication during
> implementation of oscar for our current project. The fact that it's
> verbose is not the problem, but that I can't change it sensibly without
> copying it whole, even if I want to change just one small thing (like
> the label of a dashbord navigation item). Then when we update to
> oscar-0.7 we have a manual three-way-merge on our hands for each.
>
> Thanks :)
>
> Markus
>
>
> On Fri, Nov 29, 2013 at 7:57 PM, Maik Hoepfel
> <maik.h...@tangentsnowball.com
> <https://github.com/mbertheau/django-oscar/commit/5f4deace1f800e9e7049952a809574c44da94431>.
> 'dashboard:catalogue-category-__list', ...]
> <https://github.com/tangentlabs/django-oscar>
> http://django-oscar.__readthedocs.org/en/latest/
> <http://django-oscar.readthedocs.org/en/latest/>
> https://twitter.com/django___oscar
> <mailto:django-oscar%2Bunsu...@googlegroups.com>.
> Visit this group at
> http://groups.google.com/__group/django-oscar
> <http://groups.google.com/group/django-oscar>.
> <https://groups.google.com/d/msgid/django-oscar/dad7973b-86e4-4b77-8f17-2e2d89b518d1%40googlegroups.com>.
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
> --
> https://github.com/__tangentlabs/django-oscar
> <https://github.com/tangentlabs/django-oscar>
> http://django-oscar.__readthedocs.org/en/latest/
> <http://django-oscar.readthedocs.org/en/latest/>
> https://twitter.com/django___oscar <https://twitter.com/django_oscar>
> <https://groups.google.com/d/topic/django-oscar/Gh18GXmoDrw/unsubscribe>.
> <mailto:django-oscar%2Bunsu...@googlegroups.com>.
> Visit this group at http://groups.google.com/__group/django-oscar
> <http://groups.google.com/group/django-oscar>.
> <https://groups.google.com/d/msgid/django-oscar/5298732F.9000702%40tangentsnowball.com>.
>
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.
okay, I see the problem. My assumption is that every shop in production
will use a custom dashboard navigation, so I haven't been too concerned
about it. And changes to DASHBOARD_NAVIGATION should be minimal between
releases. The likely scenario is that new navigation items will get
added. And in that case, I think forcing a decision to include or
exclude during the upgrade is a reasonable thing to do.
Do you think adding changes to DASHBOARD_NAVIGATION to the release notes
is a decent solution for now?
Regards,
Maik
On 29/11/13 11:34, Markus Bertheau wrote:
> Hi Maik,
>
> I just ported an (incomplete) app from 0.5 to master a few weeks ago and
> with that experience in mind I try to reduce code duplication during
> implementation of oscar for our current project. The fact that it's
> verbose is not the problem, but that I can't change it sensibly without
> copying it whole, even if I want to change just one small thing (like
> the label of a dashbord navigation item). Then when we update to
> oscar-0.7 we have a manual three-way-merge on our hands for each.
>
> Thanks :)
>
> Markus
>
>
> On Fri, Nov 29, 2013 at 7:57 PM, Maik Hoepfel
> <maik.h...@tangentsnowball.com
> <mailto:maik.h...@tangentsnowball.com>> wrote:
>
> Hi Markus,
>
> I'm happy to consider improvements to how the navigation is handled.
> But frankly, right now I don't see a big issue with it. Your main
> concern is that the current solution is quite verbose?
>
> For my Oscar project, I copied defaults.py into my settings folder
> anyway and named it shop_settings. That gets included in my base
> settings file. I find that a workable solution, and it ensures I
> don't miss any Oscar settings.
>
> Regards,
>
> Maik
>
>
> On 25/11/13 16:26, Markus Bertheau wrote:
>
> Hi,
>
> in our Oscar installation we need to rename and reorder some of the
> items in OSCAR_DASHBOARD_NAVIGATION. Currently this isn't possible
> without copying and modifying the whole pretty large structure.
> Duplicating it has the usual drawbacks. So we were thinking
> about a way
> to model OSCAR_DASHBOARD_NAVIGATION that makes this kind of
> customization easier.
>
> One approach we tried is in
> https://github.com/mbertheau/__django-oscar/commit/__5f4deace1f800e9e7049952a809574__c44da94431
>
> Hi Markus,
>
> I'm happy to consider improvements to how the navigation is handled.
> But frankly, right now I don't see a big issue with it. Your main
> concern is that the current solution is quite verbose?
>
> For my Oscar project, I copied defaults.py into my settings folder
> anyway and named it shop_settings. That gets included in my base
> settings file. I find that a workable solution, and it ensures I
> don't miss any Oscar settings.
>
> Regards,
>
> Maik
>
>
> On 25/11/13 16:26, Markus Bertheau wrote:
>
> Hi,
>
> in our Oscar installation we need to rename and reorder some of the
> items in OSCAR_DASHBOARD_NAVIGATION. Currently this isn't possible
> without copying and modifying the whole pretty large structure.
> Duplicating it has the usual drawbacks. So we were thinking
> about a way
> to model OSCAR_DASHBOARD_NAVIGATION that makes this kind of
> customization easier.
>
> One approach we tried is in
> <https://github.com/mbertheau/django-oscar/commit/5f4deace1f800e9e7049952a809574c44da94431>.
> However I'm not satisfied with how that turned out. The position
> key is
> obviously necessary to support reordering, but it's very
> cumbersome and
> sometimes problematic: what position do you use when you want to
> insert
> an item into the dashboard navigation between positions 0 and 1?
> 1.5 is
> certainly possible but doesn't feel right. I prefer using a
> python list
> to specify the order of items in the navigation. The second
> thing that
> makes this solution not feel right with me is the need for an
> update_dict_recursively function. That feels too complicated.
>
> Then I thought about an array that has just the url_names for leaves
> maybe like this:
>
> OSCAR_NAV_CATALOGUE = (_('Catalogue'), 'icon-sitemap',
> ['dashboard:catalogue-product-__list',
> key is
> obviously necessary to support reordering, but it's very
> cumbersome and
> sometimes problematic: what position do you use when you want to
> insert
> an item into the dashboard navigation between positions 0 and 1?
> 1.5 is
> certainly possible but doesn't feel right. I prefer using a
> python list
> to specify the order of items in the navigation. The second
> thing that
> makes this solution not feel right with me is the need for an
> update_dict_recursively function. That feels too complicated.
>
> Then I thought about an array that has just the url_names for leaves
> maybe like this:
>
> OSCAR_NAV_CATALOGUE = (_('Catalogue'), 'icon-sitemap',
> 'dashboard:catalogue-category-__list', ...]
> OSCAR_NAV = ['dashboard:index', OSCAR_NAV_CATALOGUE, ...]
>
> and have the label, icon and access_fn information somehow
> stored with
> the urls, or maybe with the associated views. However what I
> still don't
> like about that approach is that the icons and labels are
> specified in
> different places for leaves and nodes of the nav tree. We could have
> leaves in the settings as well:
>
> OSCAR_NAV_PRODUCTS = (_('Products'),
> 'dashboard:catalogue-product-__list'))
>
> and have the label, icon and access_fn information somehow
> stored with
> the urls, or maybe with the associated views. However what I
> still don't
> like about that approach is that the icons and labels are
> specified in
> different places for leaves and nodes of the nav tree. We could have
> leaves in the settings as well:
>
> OSCAR_NAV_PRODUCTS = (_('Products'),
> ...
> OSCAR_NAV_CATALOGUE = (_('Catalogue'), 'icon-sitemap',
> [OSCAR_NAV_PRODUCTS, OSCAR_NAV_CATEGORIES, ...]
>
> however if I want to replace or rename e.g. catalogue -> ranges,
> I have
> to specify not only OSCAR_NAV_RANGES in my settings, but also
> OSACR_NAV_CATALOGUE and OSCAR_NAV in order for the changes to be
> picked
> up. Also the setting names get very very long:
> OSCAR_DASHBOARD_NAVIGATION___CATALOGUE, which is another reason
> OSCAR_NAV_CATALOGUE = (_('Catalogue'), 'icon-sitemap',
> [OSCAR_NAV_PRODUCTS, OSCAR_NAV_CATEGORIES, ...]
>
> however if I want to replace or rename e.g. catalogue -> ranges,
> I have
> to specify not only OSCAR_NAV_RANGES in my settings, but also
> OSACR_NAV_CATALOGUE and OSCAR_NAV in order for the changes to be
> picked
> up. Also the setting names get very very long:
> why I
> wanted to put icon and label information with the url or the
> associated
> view, but it doesn't help with nodes.
>
> Any other ideas?
>
> Thanks :)
>
> Markus
>
> --
> https://github.com/__tangentlabs/django-oscar
> wanted to put icon and label information with the url or the
> associated
> view, but it doesn't help with nodes.
>
> Any other ideas?
>
> Thanks :)
>
> Markus
>
> --
> <https://github.com/tangentlabs/django-oscar>
> http://django-oscar.__readthedocs.org/en/latest/
> <http://django-oscar.readthedocs.org/en/latest/>
> https://twitter.com/django___oscar
> <https://twitter.com/django_oscar>
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from
> it, send
>
> an email to django-oscar+unsubscribe@__googlegroups.com
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from
> it, send
>
> <mailto:django-oscar%2Bunsu...@googlegroups.com>.
> Visit this group at
> http://groups.google.com/__group/django-oscar
> <http://groups.google.com/group/django-oscar>.
> To view this discussion on the web visit
> https://groups.google.com/d/__msgid/django-oscar/dad7973b-__86e4-4b77-8f17-2e2d89b518d1%__40googlegroups.com
> <https://groups.google.com/d/msgid/django-oscar/dad7973b-86e4-4b77-8f17-2e2d89b518d1%40googlegroups.com>.
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
> --
> https://github.com/__tangentlabs/django-oscar
> <https://github.com/tangentlabs/django-oscar>
> http://django-oscar.__readthedocs.org/en/latest/
> <http://django-oscar.readthedocs.org/en/latest/>
> https://twitter.com/django___oscar <https://twitter.com/django_oscar>
> --- You received this message because you are subscribed to a topic
> in the Google Groups "django-oscar" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/__topic/django-oscar/__Gh18GXmoDrw/unsubscribe
> in the Google Groups "django-oscar" group.
> To unsubscribe from this topic, visit
> <https://groups.google.com/d/topic/django-oscar/Gh18GXmoDrw/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> django-oscar+unsubscribe@__googlegroups.com
> <mailto:django-oscar%2Bunsu...@googlegroups.com>.
> Visit this group at http://groups.google.com/__group/django-oscar
> <http://groups.google.com/group/django-oscar>.
> To view this discussion on the web visit
> https://groups.google.com/d/__msgid/django-oscar/5298732F.__9000702%40tangentsnowball.com
> <https://groups.google.com/d/msgid/django-oscar/5298732F.9000702%40tangentsnowball.com>.
>
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
> --
> https://github.com/tangentlabs/django-oscar
> http://django-oscar.readthedocs.org/en/latest/
> https://twitter.com/django_oscar
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-oscar...@googlegroups.com.
>
> --
> https://github.com/tangentlabs/django-oscar
> http://django-oscar.readthedocs.org/en/latest/
> https://twitter.com/django_oscar
> ---
> You received this message because you are subscribed to the Google
> Groups "django-oscar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> Visit this group at http://groups.google.com/group/django-oscar.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-oscar/CAD3kammi-rODtYLF3Uhn8wJTP1O8D9MXZCK0%3DsMiV6%2Bsi8v6xQ%40mail.gmail.com.
> To view this discussion on the web visit
Markus Bertheau
Nov 29, 2013, 7:08:58 AM11/29/13
to django...@googlegroups.com
Hi Maik,
I think that would probably be overkill. For me personally it's just as easy and more reliable (mentioning that in the release notes could be forgotten) to just compare the oscar source code of the different versions. Also, OSCAR_DASHBOARD_NAVIGATION is not complicated code, but "just" data, so merge mistakes shouldn't have subtle effects, but quite obvious ones. I was actually just hoping for an easy patch, but it didn't turn out as easy as I had hoped.
Just now django-oscar-accounts crossed my mind. It specifies in its installation instructions to add the necessary stuff to OSCAR_DASHBOARD_NAVIGATION to have the accounts section show up. This would be another use case that could be accounted for here.
So I'll just think about that some more and if I can think of something I'll make another proposal :)
Thank you for your thoughts!
Markus
On Fri, Nov 29, 2013 at 8:52 PM, Maik Hoepfel <maik.h...@tangentsnowball.com> wrote:
Hi Markus,
okay, I see the problem. My assumption is that every shop in production will use a custom dashboard navigation, so I haven't been too concerned about it. And changes to DASHBOARD_NAVIGATION should be minimal between releases. The likely scenario is that new navigation items will get added. And in that case, I think forcing a decision to include or exclude during the upgrade is a reasonable thing to do.
Do you think adding changes to DASHBOARD_NAVIGATION to the release notes is a decent solution for now?
Regards,
Maik
On 29/11/13 11:34, Markus Bertheau wrote:
Hi Maik,
I just ported an (incomplete) app from 0.5 to master a few weeks ago and
with that experience in mind I try to reduce code duplication during
implementation of oscar for our current project. The fact that it's
verbose is not the problem, but that I can't change it sensibly without
copying it whole, even if I want to change just one small thing (like
the label of a dashbord navigation item). Then when we update to
oscar-0.7 we have a manual three-way-merge on our hands for each.
Thanks :)
Markus
On Fri, Nov 29, 2013 at 7:57 PM, Maik Hoepfel
an email to django-oscar+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/django-oscar.
To view this discussion on the web visit
--- You received this message because you are subscribed to a topic in the Google Groups "django-oscar" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-oscar/Gh18GXmoDrw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-oscar+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-oscar/52988004.3000706%40tangentsnowball.com.
Reply all
Reply to author
Forward
0 new messages