design pattern to handle multiple groups from the same view

[Abraham Varricatt]

Hello everyone,

I'm working on an e-commerce site. There is a generic version of the site available to the open internet and customized versions available to enterprise users. Now, when I say 'customized', I'm mostly talking about really minor customization's. If the current user belongs to ABC organization, change the menu display order. If she comes from XYZ company, don't show certain options .. etc. A lot of our view code looks like this;

def view1(request):
    ...
    ...
    if (request.user.company == 'ABC'):
       context['ABC-option1'] = 'something'
       ...
       context['ABC-option3'] = 'different'
    ...
    if (request.user.company == 'XYZ'):
       context['XYZ-option1'] = 'an option'
       ...
       context['XYZ-option3'] = 'manager'
    ...

    ...
    return render(request, 'templates/index.html', context)

The template isn't any better. Sure, we inherit from a base.html, but there is a LOT of if..else..if set of statements scattered everywhere. 

My instincts tell me that there has to be a better way of handling this situation - that there has to be a better way of handling these different scenarios than using so many if-else statements everywhere. I'm aware that I could set something up using inheritance in my views, but .. ... well, what I'd like is some way to handle the different scenarios OUTSIDE the views and templates. Something like say, if I have an about-me page, for all my users I want to be able to do,

def about_me(request):
    ...
    return render(request, 'aboutme.html', context)

Primarily, this is about keeping the code clean. All the about-me view function should (ideally) do is return a view. It (ideally) shouldn't have to worry about which organization a user might belong to, in-order to show a different set of addresses!

Any suggestions/alternatives will be appreciated.

-Abraham V.

[Filipe Ximenes]

An alternative [but not a simple one] is to have this customisations as a generic configuration in a database table. 

If changes are "visual" only, you could have multiple templates and only change the one you are rendering for given client. Or have this handled by template tags. "Partial templates" may also help.

It really depends on what is changing and how many of this customisations you need.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4ffb12d3-27cc-4efb-9957-1001ebe7db85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Filipe Ximenes +55 (81) 8245-9204 Vinta Software Studio http://www.vinta.com.br