Re: [Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Hi Itai, Good idea! I'll try to add this to the example. thanks! -steve Itai P.S. I've been struggling with a problem that might get Itai cleared up if you added it to the example: Itai Say you want to allow a user to add a ToDo from the Itai Deliverable screen (in addition to the existing menu for Itai selecting existing ToDos). You could either place a 'create Itai ToDo' form right there, using a UI snippet from ToDos, or Itai link to ToDos.addToDoForm. The problem is how to get the id Itai of the new ToDo into the deliverable. If you didn't store Itai todo_ids in Deliverable, instead calling Itai ToDos.getToDosForDeliverable(), there would be no Itai problem. Otherwise, you'd need a addToDoInterface in Itai Deliverable, which will call ToDos.addToDo, then add the new Itai ToDo id to todo_ids. Or, as a third option, you could pass a Itai method to ToDos.addToDo, and get it to call this method and Itai give it the new id. Itai What do you think? Want to tackle this in the example? Itai Itai -- Itai Tavor "Je sautille, donc je suis." C3Works Itai [EMAIL PROTECTED] - Kermit the Frog Itai "If you haven't got your health, you haven't got anything" ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Hi Itai, "Itai" == Itai Tavor [EMAIL PROTECTED] writes: Itai I'm already using globally unique ids, but still, doesn't Itai using the same id for the Participant and the Actor make Itai these objects too tightly coupled? Seems to me that Actors Itai should provide an interface for finding actors to the rest Itai of the application; other objects should not make Itai assumptions about the internal storage of Actors, and Itai particularly what ids they use. No? Well... there are two aspects here: 1) Who knows about how various Participants and Actors are managed and 2) How are they actually managed. Tight coupling is only about "1". It seems to me that "2" is up to you as the developer to decide based on the particular situation. I'm sure that ZPatterns Zen is like most things... you learn by getting your fingers burnt ;-). However it seems to me that it should be OK for an Xs Specialist to implement getXforY( y_id ) or getXsforY( y_id ) (if there is more than one x for a single y. If you have an XOR relationship, with several potential Specialists I think you could either: (A) iterate through the list of possible Specialists and ask each to getXforY until you get a hit... or (B) have a 'clearing house' Participants specialist, with a Rack for each of the Participant types and let it iterate through the racks and return an object of the right type based on which one is a 'hit'. (Specialists of course do this automatically!) The advantage of (A) is, one less Specialist. The disadvantage is that the Actor Specialist needs to 'know' about the list of Participant Specialists itself. The advantage of (B) is that the clearing house Specialist keeps track of all the different Participants types... and the iteration is 'automatic'. However... I think that either of these is 'OK' as far as coupling is concerned. In both cases the information about the different types of Participant is kept in a single centralized place [(A) in the Actors Specialist] and [(B) in the clearing house Specialist]. *If* you had some *other* Specialist that also needed to iterate through the various types of Participants... *then* B would be a clear advantage, and probably worth the added complexity. Anyway.. just my random thoughts. -steve (P.S. it was refreshing to hear pje mention that he and Ty had to "bite the bullet" and add new classes/Specialists on a project and only *after* that it got much simpler, clearly implying that the original design was less than perfect. It seems to us newbies sometimes that they possess the Deific characteristic of near (object oriented) infallibility whereby they produce clean, elegant, yet simple object oriented designs with the same graceful ease with which they might compose a grocery list, while we mortals struggle for hours and days to come up with something that they might discard after a moment's thought. Anyway in the end we'll all learn the most by hard experience, if only she were a more forgiving Mistress!) (P.P.S. I still really like your idea of codifying some of these ZPatterns techniques into a sort of gallery of ZPatterns Implementations. I'm working already on incorporating some of these into the ToDo example.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Hi Itai, Ok.. I'm working an DumbZPatternsExample V3.0 so this is exactly the sort of conversation that needs to take place for me. ;-) Godd to hear that (both that the discussion is helping you, and that you're working on a new dumb example :-) ) It seems to me that when you want a Reseller, or a Customer you certainly want to go to the Resellers or Customers Specialist and ask for the Participant. So.. since there is never more than one Actor for each Participant, I think I'd keep the information about the actor_id in the Participant. I might even suggest that you could use the actor_id as the participant_id, depending on how these id's are implemented. (it seems that it would be particularly nice if the ids are known to be globally unique that you could use this fact to help identifying relationships...) I'm already using globally unique ids, but still, doesn't using the same id for the Participant and the Actor make these objects too tightly coupled? Seems to me that Actors should provide an interface for finding actors to the rest of the application; other objects should not make assumptions about the internal storage of Actors, and particularly what ids they use. No? Now.. you seem to be asking how to run it the other way around. How do we get the correct Participant from the Actors specialist? Hmm... I'm not sure what the scenario would be that would require this, but it seems to me that it's a reasonable enough possibility. Well, Actors store user info such as login_name, password, and roles. So it's natural (I think) for acl_users to authenticate against Actors, rather than ask each Participant Specialist to search all the Actors associated with its Participants. So AUTHENTICATED_USER is an Actor. But the application needs to know the Participant - for example, if a Customer is placing an order, she will be asked to identify her Reseller. But if a Reseller is placing the order, the application already knows the Reseller, but it needs to ask for a Customer. So, from the Actor, I need to know the Participant type, id, name, etc. Unless, of course, I'm making things too complicated again, and it really is better to authenticate Participants rather than Actors... How about a little search... : PythonScript: getParticipantFor( self, participantSpecialistList ) while Participants in participantSpecialistList: theParticipant = Participants.getParticipantForActor( self.actor_id ) if theParticipant is not None: break return theParticipant It's up to the 'Participants' Specialists to implement getParticipantForActor based on the actor_id. (if actor_id is the same as reseller_id then it's just getItem!) Now... to make this slick, add an attribute handler for your actor that does this automagically when you ask for 'participant'. I think something like: WITH self.getParticipantFor( [Resellers, Customers] ) COMPUTE myParticipant = RESULT or NOT_FOUND should do it. In code you just say: resellerName = self.myParticipant.name or somthing like that. Of course.. I've not tried this. But it *seems* like it should work. ;-) I imagine it would... and it looks pretty good. The question is, and that brings us back to the object connections table, whether this is really the way you would want to do it. Itai -steve "Itai" == Itai Tavor [EMAIL PROTECTED] writes: Itai There might be many ways to implement each connection, but I Itai think that there will always be one or two ways that would Itai be simplest and most robust... so this would not only save Itai you the trouble of figuring it out alone every time, but Itai would also prevent you from getting stuck down the road. Itai The problem is that we have at best guesses, and at worst Itai empty table cells in the guide. I'm still struggling with Itai many of these... The worst one seems to be XOR type Itai connections, where a Specialist implementing a role is not Itai involved. Example: Itai Actor: Person. Itai Participants: Customer, Reseller Itai Object connections: (Customer) 1---[XOR A] 1 (Actor) Itai [XOR A] 1---1 (Reseller) Itai acl_users Login Manager authenticates users using Actor Itai objects (by connecting the the Actors Specialist). The Itai application needs to identify the Participant. Itai If you add participant_id to Actor, you still don't know Itai which Participant Specialist to load the Participant Itai from. You don't want to add participant_type to Actor (at Itai least, I don't think you do - it seems real ugly). So, what Itai do you do? Do you place the Customers and Resellers Itai Specialists inside a Participants Specialist? We'll have to Itai call it MegaSpecialist :-). Bad idea - other parts of the Itai application have to access Resellers specifically, so Itai Resellers should not be hidden inside
