Thanks a lot Whit and Mike, it helped me a lot in understanding the implementation of traversal and understanding the precautions to be taken.
However coming back to my original question of possibility of having same objects in two hierarchies in same application still puzzles me ( just leaving aside the example which I gave in my original question), moreover existence of traversal_wrapper has also caused another confusion to me i.e. unable to store those resources in repoze.catalog's document map due to lack of hardwired location awareness in them. Don't you guys feel that having same object in two hierarchies is a common scenario or am I somewhat misplaced in my understanding (at least existence of traversal_wrapper suggests that there are scenarios) ? Thanks, Anurag On Thursday, January 31, 2013 2:47:37 AM UTC+5:30, Mike Orr wrote: > > I'm not a traversal expert but here's my 2c. > > On Tue, Jan 29, 2013 at 11:27 PM, anurag sharma > <[email protected] <javascript:>> wrote: > > I'm using traversal/zodb for my pyramid application. However I'm a bit > > confused whether I'm using traversal/resource/tree structure properly or > > not. > > The thing which is confusing me the most is the parent concept in tree, > > where we have to define parents for our resources while creating them. > > > > For explanation I'm trying to present a small problem and will like to > know > > what should be the correct approach for this kind of situation: > > Suppose we have a college class management system. There are two classes > > class A and class B, a student 'XYZ' can be a part of one class or both > the > > classes. > > How I would design it is like this : We have root as college and under > root > > we have a container called classes and a container called students. > > So when student XYZ is created in system it is added in a container > called > > students, and when he was admitted for class A, he was also added to a > > container(for students in that class) inside class A resource. Both the > > objects are the same (students/XYZ is classes/classA/itsStudents/XYZ ) > > In this case I can't have a parent in student instance when it is > created, > > so I will use pyramid_traversalwrapper which will allow to assign parent > > dynamically based on the request. If url is students/XYZ , locationproxy > > will have parent as students and if .../classA/itsstudents/xyz then it > will > > be according to it. > > > > My question here is that whether my approach and application/usage of > > traversal is correct here or will it be done differently from > experienced > > pyramid traversal developers. > > Traversal has a small niche where it's significantly better than URL > Dispatch, and a much larger niche where either Traversal or URL > Dispatch are equally effective but they lead to different code > organization. > > The case where Traversal is significantly better is when you don't > know beforehand which object types will be at which URLs, especially > when users are allowed to create a tree structure rather than a flat > namespace. Content management systems are the quntessential example of > this. > > However, many applications have a fixed URL structure, and a class > management system may be one of those. You said your URLs are like > "/classes/{class_id}/students/{student_id}". In that case, Traversal > vs URL Dispatch is mostly a preference choice. The advantage is that > the dispatcher will look up the resource for you and present it as the > "context", with parents. Otherwise you'd have to look those up > yourself in the view. How much difference does it make? Not much, just > using "context" vs another variable. > > And you have to create a resource tree, which wouldn't be necessary > without Traversal. This adds a certain amount of work, so the question > is, how much unique benefit can you add at the same time? It gives the > opportunity to move some of the code in (URL Dispatch) views into the > resource and its parents, as methods or attributes. In other words, in > ordinary (URL Dispatch) model objects, you have your column > attributes, and you may also have some methods and non-persistent > attributes. In Traversal, you can add additional methods and > attributes beyond that to the context and its parents, things that > leverage the Traversal structure and lead to better organized code, > maybe. That "maybe" is important, because is it really better > organized, or are you trying to shoehorn things into the > resource/parent structure that don't really belong? > > There hasn't been much written about what kinds of things are worth > pushing into the resource structure in a fixed-URL application, so I > don't really have an answer. Sometimes I think about putting index > wrappers; e.g., where "/articles" is an index page for "/articles/X". > In that case, I don't need the full child objects, but just enough > fields to generate the index page and do searches and the like. So > should I make the index result list (or a paginator of it) into the > "context" of the index view? But what have I gained? It's just moving > a query from one place to another. Whether it's called "context" or > not is perhaps unimportant. And when I go through the parent to a > child context, I don't want the parent generating a superfluous query > I'll never use. > > Similar issues come up in building up breadcrumbs links or > neighbor-navigation links. If the parent generates a query just by > traversing it, then you're continually having root queries and section > queries on every request. And to get that list of neighbor-links > (siblings, etc), you'd have to go far and wide through the resource > tree on every request, and if you naively make it fetch all these > other nodes entirely rather than using a limited index query, you end > up fetching a whole lot of stuff you won't use in that request. So > these things *can* be done via the resource tree, but it's not > necessarily always the ideal way. > > Another issue is generating URLs to other nodes. It's easy to generate > the context's URL or an ancestor's. But what about another node? Is it > really worth fetching that object through the tree and asking it its > URL? Or is it OK to just hardcode the URL down from a resource you > already know (the root or an ancestor); e.g., > 'request.resoufce_path(root, "other_view")' or > 'request.resource_path(root, "other_section", "other_view")'. I used > to avoid that as improperly hardcoding names, but now I'm starting to > wonder, because the method *does* seem to explicitly have that > capability. > > Anyway, those are my current thoughts about traversal. > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
