Forums / Setup & design / Object Relatedness Vs. Container Objects: Pros and Cons

Object Relatedness Vs. Container Objects: Pros and Cons

Next topic

Author	Message
Massimiliano Bariola	Monday 10 October 2005 4:30:12 am Hi, I am about to design the information structure of a rather big and complex project. I wanted to take advantage of this opportunity to inestigate in depth pros and cons of the 2 main features eZ publish offers to relate content: Object Relations and Container Objects. I don't want to give details of the specific project because this would bias the discussion of the two approaches, while what I am looking for, is to have the community's feedback on strenghts and weaknesses of both, and leaving a "document" that everyone can use to assist in design decisions. Pros and cons should be evaluated from the points of view of: - user admin interface management - content management (scalability, expandability) - programmatical issues (PHP code of extension which will interface with the data) My first seed: Container objects: Pros: easy to understand for untrained content editors, "all stuff in one place". Easy to do hierarchical operations (section assigning, moving, etc) Cons: Rigid. Object Relations: Pros: flexible. Cons: scattered info, difficult to get an idea of how information is interdependent "at a glance". This is a really skimpy list, everyone is welcome to add to it.
Gabriel Ambuehl	Monday 10 October 2005 6:30:33 am On one side, it's a matter of taste and style. Personally I prefer EOR (as if anyone was surprised by that) as it more closely remembers a link or even a join like in the relational model. The container stuff is more aking to a traditional hierarchical filesystem which is often not flexible enough for those uses. What I can say for sure: objects that need to live in different places generally are best done as some sort of relation as the relations have a much easier interface than the multiple location system. > Relations: difficult to get an idea of how information is interdependent "at a glance". True. But you're invited to write some graph algorithm to graph the interdependencies on a site if you care ;) I'm not quite sure if the idea of container objects is easy to understand. In my mind, easy drop down boxes for selections are much easier to grasp than the correct placement of children. Visit http://triligon.org
Massimiliano Bariola	Monday 10 October 2005 8:45:35 am >> Relations: difficult to get an idea of how information is interdependent "at a glance". >True. But you're invited to write some graph algorithm to graph the interdependencies on a site if you care ;) It's not my intention to extend the mechanism, but rather examining what's out-of-the-box, though yes ... it could be a feature for when a chain of relations grows too much. Something to be said for containers is that it's easy to determine and set section of belonging / visible / not visible. so just because it resembles a filesystem, it is also more akin to an user's experience. especially if he is hierarchically-minded.
Gabriel Ambuehl	Monday 10 October 2005 11:13:18 am Truth to be told, most users store documents in Word and in Powerpoint and can't be saved from that idea... Filesystem hierarchies are totally lost on them. Explaining them relations as "like links in the Web" might even make more sense to some. Visit http://triligon.org
Massimiliano Bariola	Tuesday 11 October 2005 1:49:05 am Following the paradigm of "links in the web", let's assume we are talking of relating objects via a dataype and not through the admin interface. I still have not used them that way. From the point of performance and simple working-out, where does it make sense to put the datatype? In a scenario where you cannot decide which kinds of objects will be related to which other, i.e. If object A is related to B, would we put an object-relation datatype in object A, object B, or both? I suppose it is better to put it in both places and maybe use it only if needed. i.e. if usually class A is related to class B, it would make sense to keep the object-relation datatype in class A and work from B to A with reverse relation. To ease management and make the system more flexible, an object realtion datatype in B would be a good idea. right ?
Xavier Dutoit	Tuesday 11 October 2005 5:56:41 am I'd say that using the enhanced object relation would be a better idea, but I'm slighly biased ;) I've been able to explain the difference between locations and related objects, some of my customers even understood it, but the reverse relation has always proved be a nightmare. I know you can use either relations or relations, that you can have more than one location to confuse them a wee bit more, but from a conceptual point of view, they don't address the same need, and that isn't that complicated to explain that. locations= "belongs to", relations = "see also". On most of the cases, it works well: "staff" goes under "about us" and that's easy to understand. For the 10% more complex where you can have several ways of categorizing a page, you decide of what's the main one and you force them to stick to it. On the real live, lots of things have more that one way to be stored (eg a book could be stored by its author name, by topic, by title...). If they are able to find a book on a library shelf, they should be able to understand how it works on ez! On some cases, the choosen classification system is better than the others only because it's the choosen one and everyone is going to apply it. Coherency is the key for everyone. Use the location for the main classification, related objects for the rest and after a lot of scream, pain and cry, you are going to have a fucking mess of a website ;) Good luck... X+ http://www.sydesy.com
Fraser Hore	Thursday 27 October 2005 2:23:49 pm I'm wrestling with the same question of locations versus relations. One of the challenges with object relations is that objects can't be filtered or sorted when fetching reverse relations (as far as I'm aware). Filtering has to be done at the time of printing the content with IF statements, which is cumbersome, and i have no idea how you can sort. Any suggestions here would be very helpful. A challenge to both approachs is the need to allow the user to relate two objects while creating/editing EITHER object. You can put a relation datatype in both classes but then you have to get rid of duplicate objects in your template code. I've tried using the Unique operator and that hasn't worked too well. Any suggestions here? Another challenge to both approaches is when you need to select locations or related objects from a very large list. For example, if you were to editing a contant person object and you wanted to associate that contact with a company. If you have hundreds of companies it's pretty difficult to find the one you want. The browse approach could be ok because i suppose you could override the browse template and add things like letter tabs or even a search function. BUT, you can't pick a top node with either of the built in object relations datatypes, which is frustrating. The enhanced object relation is awsome, but it doesn't include the browse function. Any suggestions for this problem? I hope this raises some challenges that others are struggling with as well and leads to so good solutions suggestions! Cheers, Fraser