On Wed, Jun 1, 2016 at 5:21 AM, <sevenrrain...@gmail.com> wrote: > I'm creating a basic CMS. The CMS will contain information about different > Entities. > > > A normal users can only see the information about the Entities but an > editor will have access to an Dashboard were it can add new Entities or > updated them. > > I have an app Entity that use class-based view (CBV) for > create,update,details,list-display (CRUD). > You'll probably need to implement a permission system to control access to resources.
> > The urls for listing and details are: /entities and /entity-name > > > Because update and create are behind login and use different urls I create > a second app Dashboard that use the create/update models of the Entity app > One app can handle multiple URL schemes, both for anonymous and authenticated requests simultaneously. You really only need multiple apps when there is a clear separation of duties/functionality. They're really more for organization of the code than any functional/technical reason. > > The urls are account/add and account/edit. > > > *There is another solution to have different urls for views of the same > model ?* > > > You can have as many views as you'd like for the same model. It is common in situations where an object can be in different states at different times. For example, an account is created for a user, so the user needs to claim it, and then the new user needs to modify their own account with the right details and change passwords, etc. That may also include having multiple forms for the same object as well. I want the fist page of the dashboard to show different information based > on the following logic(exist and/or is activated): > > - if doesn't exist I want the CreateView (CBV) and corresponding form > to appear > - if exist but it is not active a Pending message > - if exists and active the data of the entity > > I can do the logic at the template level, but to separate things is better > to be done at the CBV level. So in this case I need some help, how to > implement it. > Well, yes, and no. I wouldn't rely solely on the template to handle this behavior. You'll be twisting yourself into a pretzel to make it work. There's a couple of ways to make this work: - Have a single view that initially examines the situation, and then calls the respective functions or CBV's that handle the specific situation. Keeps the request logic within the view infrastructure, but not a typical strategy as far as I know. The same URL can then serve all of the situations. - Have a single view that builds a basic page structure, and use a JS framework and AJAX calls to build an SPA that displays the right information. - Have a separate view for each situation, along with a separate URL, and another view/URL for the main dashboard. Have the main dashboard view check for your logic, and redirect the browser to the URL for each action. Once the situation is corrected (form submitted, etc.) then redirect back to the main dashboard. This would be my preferred method. You can use template inheritance in all of these situations to keep the amount of template code down (which is generally advised since the template system tends to be the slowest part of Django). -James -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVf2DJ4NnVjcr9y%2B3SwS-T3eqS7vzEFVCnkfypJTE2D6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
