PageQuerySet.all_root fundamentally wrong

Showing 1-6 of 6 messages
PageQuerySet.all_root fundamentally wrong simon harrison 9/14/12 8:38 AM
i posted this in the django-cms group but no replies... maybe here is more appropriate. all advice/feedback appreciated. thanks

original post.....

There should only be one root to a site. I can't understand how something like this can be allowed:

    def all_root(self):
        Return a queryset with pages that don't have parents, a.k.a. root. For
        all sites - used in frontend
        return self.filter(parent__isnull=True)

This makes configuring a new site with Django CMS very very unintuitive. Look, the doc string even says 'a.k.a. root'. That means ONE.

This is even worse:

    def get_home(self, site=None):
            home = self.published(site).all_root().order_by("tree_id")[0]
        except IndexError:
            raise  NoHomeFound('No Root page found. Publish at least one page!')
        return home

Are you 100% confident what this will return you? What if I move siblings about? Unpublish an older sibling? Moveable roots...? Ordered by tree_id... really? There should be ONE root.

Django CMS seems to encourage having multiple roots to a site... existing as a bunch of siblings at the root. This is fundamentally wrong. Or if i am mistaken some clear examples should be added to the docs .

Am I totally mistaken?

How would you configure a page called 'home' in the menu tree that has slug '/' which has children and childrens children where 'home' never appears in their path.

Warmest regards,
slightly frustrated Django CMS user

Thanks! 9/14/12 5:07 PM <This message has been deleted.>
Re: PageQuerySet.all_root fundamentally wrong Christopher Glass 9/15/12 3:50 AM

Demanding answers is not very constructive. Suggesting changes would be.

Now that this is out of the way, your assumptions are correct, the CMS does consider top level pages as "root". The reason for that is mostly historic. Perhaps the choice of words was poor.

It works quite decently for a large number of users (and a proportionally large number of websites).
Pull requests are welcome if you feel your implementation would be better.


- Chris

PS: This is a mailing list, you don't need to bump threads. And no, you can't have a pony.

On Sep 15, 2012 2:07 AM, "simon harrison" <> wrote:
come on devs.... respond!!
Re: PageQuerySet.all_root fundamentally wrong simon harrison 9/15/12 4:58 AM
Hi Chris

Yeah, there are better times to compose posts than 1am....sorry

But thanks for your response.

Can you elaborate on the 'historical' reasons please? I have a reasonable amount of experience with developing CMS's and I can't think of any reasons why to break from this convention.

And the reason I sought out these methods and raised the post is that Postgres through back some crazy crazy results for a home page in production after a client started adding and removing pages. Now I assumed this was a caching issue but am able to replicate it in dev (considering/clearing all caches). So then I checked the tree and saw the multiple roots. I created the same tree again with one root and now I'm stuck with 'home' in all the url paths. I'll revert back to what is considered 'normal' for DCMS and maybe submit a bug report if I can replicate the same problem again.

Ta Chris

p.s. no need for a pony
Re: PageQuerySet.all_root fundamentally wrong Luke Crooks 9/15/12 7:30 AM

It's an open source project, if you feel you can make an improvement send a pull request and we can discuss it there.

The current structure works perfectly for all current users, so I really don't see why its all of a sudden such a big issue.

If you don't like it, there are plenty of cms platforms available (maybe WordPress word suit you).

Or of course you can write your own cms.

Re: PageQuerySet.all_root fundamentally wrong simon harrison 9/15/12 7:45 AM
It may well work well for most but I was trying to find out the motivation for the approach. It's not conventional. Can you explain?

And yeah, I am now trying out others, but not WordPress.