howdy anurag, On Jan 30, 2013, at 1:27 AM, anurag sharma <[email protected]> wrote:
> Hi Friends, > > 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 ) [I'll give this a shot, with the proviso I may just make you more confused] I would posit traversal is a system for modeling how clients will interact with your application, not necessarily a way to model how your application should interact with it's data (though they are related). The close coupling of the zodb persistence to the traversal mechanism blurs this separation a bit vs. say using normalized tables in SQL where you would start with these concepts uncoupled. The critical difference lies between the concept of a context and a data "object" like an ORM would hand you. It is a bridge between your external representation (how/what a client can get out of your app) and your internal representation (how your app gets things done). Using traversal with the ZODB means that your internal representation is going to be pretty closely tied to your external representation, but not completely. Considering your example, I think you actually have 2 different types of data for students. #1 /students/XYZ would be a representation of the student for the system (name, age, SSN, credits completed, etc), and #2 /classes/classA/XYZ would be representation of the student in that class (grades, teacher's notes, etc). In this case, I think you want an object hierarchy with a containerish objects (maps, lists) for Students and Classes that holds Students and StudentClassInfo. To do sensible things you would most likely want to maintain some sort of relationship between Students and StudentClassInfo. This could either use something as simple as ids (see example below) or perhaps by maintaining a simple index composed out of zodb BTrees depending on what kinds of lookups you need. How would this work? say you had a view 'about' for a student in the class. http://myapp/classes/BasketWeaving/Bob/about It displays some basic information - Name: Bob Johnson - Current Grade: F - Notes: Bob lit last basket on fire. Traversal would return the "about" view with the context StudentClassInfo (sci). In this case, sci.__name__ == 'Bob', so the view could simply walk back up the object tree to 'root' then access the student instance ala 'root.students['Bob']' to retrieve data such as the full name. The grade and notes would accessible via the sci instance. -w d. "whit" morriss Platform Codemonkey [email protected] -- 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.
