That's the main thing about this structure. It is unlikely to change very 
often, but I don't want it set in stone because there's always a chance it 
will change. And it will display on most, if not all, pages in this 
project. But all that caching, etc., is stuff I can deal with later.

Because it'll be *primarily* two levels, I figured the AL approach would 
work best, which is why I chose that when writing this class. But given 
what I've got, how do I ask, "What are all the children of this node?" Do I 
do so in the template, or in the defining view? That's the question I'm 
having trouble answering.

James C

On Thursday, September 5, 2013 10:43:14 AM UTC-5, Javier Guerra wrote:
>
> On Thu, Sep 5, 2013 at 10:22 AM, James <jcla...@gmail.com <javascript:>> 
> wrote: 
> > I started writing a new model for a client's website. The easiest 
> analogy I 
> > can make is something like a menu, so I wrote just that (start simple, 
> then 
> > add the hard stuff). 
>
>
> the main aspect to choose between "just a parent link" (Adjacency 
> List) and a full tree library (typically nested sets or materialized 
> path) is the frequency of full (sub) hierarchy requests. 
>
> if in most cases you have a given node and just need to get all the 
> direct children, then the simplest solution works great. 
>
> if, on the other hand, you have to get a whole subbranch at 
> indeterminate depth, then use something else. 
>
> I guess that most pages will have to display the whole menu tree, so 
> using nested sets seems better since it would add just a single query. 
>  But if it is the _whole_ tree, then you could just as easily read the 
> whole table and unravel the hierarchy in python.  Even better, if the 
> menu doesn't change so often, you should store the rendered structure 
> in some cache and don't care about the base structure.... 
>
> -- 
> Javier 
>

-- 
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 http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to