ZPatterns: Deleting objects from a Rack?
Ok, I have a stupid question. I have succeeded in creating a ZClass (a subclass of DataSkin) and instantiating a few instances in the defaultRack of my Specialist using my Specialist's newItem() method. Rock. However, search as I might, I cannot figure out how to delete an item once it's been created. On gut instinct, I figured there would be a deleteItem() to complement the newItem() method. No such luck. What am I missing? Is there a management tab I'm not clicking on somewhere? A method I haven't found? A clue I don't have? :-) Thanks, --Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:jeff.hoffman@goingv.com Going Virtual, L.L.C. http://www.goingv.com/
In article <Pine.SOL.4.10.10006220021020.6043-100000@argyle>, Jeff Hoffman <jeff.hoffman@goingv.com> wrote:
However, search as I might, I cannot figure out how to delete an item once it's been created. On gut instinct, I figured there would be a deleteItem() to complement the newItem() method. No such luck.
What am I missing? Is there a management tab I'm not clicking on somewhere? A method I haven't found? A clue I don't have? :-)
call the manage_delete() method on the object. That is, you ask the object to delete itself. getItem() and newItem() aren't methods of the objects because it doesn't make sense... if you have the item, you don't need to get it. And you can't ask an object that doesn't exist yet to create itself :-). However, once you have the object, operations on the object should be done as methods on the object.
Ty Sarna wrote:
call the manage_delete() method on the object. That is, you ask the object to delete itself.
This seems unnecessarily long-winded to me. What are the reasons for it being like this? (examples are good... ;-)
However, once you have the object, operations on the object should be done as methods on the object.
I'm sure it's against Demeter's Law (I've read the Wiki ;-) to work this way. You should ask the rack to delete an object and it can process this how it wants... most often this would be by asking the object to delete itself, but maybe it's be more efficient for the rack to just delete the object (for example, if the object is actually a row in an SQL table) cheers, Chris
Thus spake Chris Withers (chrisw@nipltd.com):
Ty Sarna wrote:
call the manage_delete() method on the object. That is, you ask the object to delete itself.
This seems unnecessarily long-winded to me. What are the reasons for it being like this? (examples are good... ;-)
However, once you have the object, operations on the object should be done as methods on the object.
I'm sure it's against Demeter's Law (I've read the Wiki ;-) to work this way. You should ask the rack to delete an object and it can process this how it wants... most often this would be by asking the object to delete itself, but maybe it's be more efficient for the rack to just delete the object (for example, if the object is actually a row in an SQL table)
I could be mistaken about this, as I'm still having trouble following the ZPatterns train of thought, but I think the reason that the object needs to delete itself is that the object may not be stored in a single place. For instance, the object might be created from 5 rows from seperate tables in an SQL db and 2 attributes gotten from LDAP. I'm not entirely clear how asking the object to delete itself in this case is going to improve the situation over just asking the rack to, but I think that was the intent. sRp -- Scott Parish http://srparish.net
Scott Parish wrote:
I'm not entirely clear how asking the object to delete itself in this case is going to improve the situation over just asking the rack to, but I think that was the intent.
Okay, I see the intent now too, but I agree with you that I can't see what advantage asking the object to delete itself provides. Could someone explain please? Furthermore, even if there was an advantage to this, why can't the rack's delete method just be piped through to the object's delete method? (which I thought was common practice with Specialists) cheers, Chris
Chris Withers wrote:
Scott Parish wrote:
I'm not entirely clear how asking the object to delete itself in this case is going to improve the situation over just asking the rack to, but I think that was the intent.
Okay, I see the intent now too, but I agree with you that I can't see what advantage asking the object to delete itself provides. Could someone explain please?
Furthermore, even if there was an advantage to this, why can't the rack's delete method just be piped through to the object's delete method? (which I thought was common practice with Specialists)
cheers,
What happens when the object is in multiple racks? (Assuming it is possible)
Bill Anderson wrote:
What happens when the object is in multiple racks? (Assuming it is possible)
Then it'll be missing if something tries to get it from a rack. The same thing as would happen if something tried to get it from a single rack after it'd been deleted. So this case should be covered anywhere as it's essentially 'what happens if an object that doesn't exist is requested from a rack?' That said, can you give em an example where it would eb useful to have one object stored in multiple racks? cheers, Chris
Chris Withers wrote:
Bill Anderson wrote:
What happens when the object is in multiple racks? (Assuming it is possible)
Then it'll be missing if something tries to get it from a rack. The same thing as would happen if something tried to get it from a single rack after it'd been deleted. So this case should be covered anywhere as it's essentially 'what happens if an object that doesn't exist is requested from a rack?'
Actually I was thinking of the case where it may, or may not, need to delete itss elf from multiple racks it sits in.
That said, can you give em an example where it would eb useful to have one object stored in multiple racks?
Not quite sure, but I get a feeling some of the advanced ideas for portal content could make use of it. It's just a gut feeling, I'm still wrapping my brain around ZPatterns . ;) Lemme think about it, I am sure I can come up with one or two. As to whether there would be any advantage to it, would be another thing. ISTR someone talking about possibly using multiple racks recently. -- "Linux: the operating system with a CLUE... Command Line User Environment". seen in a posting on comp.software.testing
Thus spake Chris Withers (chrisw@nipltd.com):
Scott Parish wrote:
I'm not entirely clear how asking the object to delete itself in this case is going to improve the situation over just asking the rack to, but I think that was the intent.
Okay, I see the intent now too, but I agree with you that I can't see what advantage asking the object to delete itself provides. Could someone explain please?
Furthermore, even if there was an advantage to this, why can't the rack's delete method just be piped through to the object's delete method? (which I thought was common practice with Specialists)
Another thought i just had was that if you deleted by placing a call to the Rack, then you couldn't allow the class to override manage_delete. You might want to do such (overriding) if you wanted it to clean up a catalog or perform some other auxiliary function before disappearing. sRp -- Scott Parish http://srparish.net
Scott Parish wrote:
Another thought i just had was that if you deleted by placing a call to the Rack, then you couldn't allow the class to override manage_delete. You might want to do such (overriding) if you wanted it to clean up a catalog or perform some other auxiliary function before disappearing.
What class are you talking about? ;-) This is why I said it might be useful for the rack's delete just to call delete on the object. I think this is me going on about the demeter's Law thing again... cheers, Chris
participants (5)
-
Bill Anderson -
Chris Withers -
Jeff Hoffman -
Scott Parish -
tsarna＠endicor.com