d. "whit" morriss Platform Codemonkey [email protected]<mailto:[email protected]>
On Feb 7, 2013, at 1:30 PM, Anurag <[email protected]<mailto:[email protected]>> wrote: 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. I sort of touched on this in my scree, but basically, the hierarchy that makes up the URL must be unique as does the address in the zodb. So the best you can do is fake it wrt two places at once. But that's why you have views... -w 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]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[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. -- 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.
