| 01:39.18 | *** join/#storm vvinet (n=vince@modemcable101.133-202-24.mc.videotron.ca) |
| 06:02.23 | *** join/#storm jukart (i=lovely@81.189.156.94) |
| 06:02.51 | *** join/#storm oubiwann (n=oubiwann@97-119-81-226.omah.qwest.net) |
| 07:58.09 | *** join/#storm goschtl (n=goschtl@p5B0BFC2B.dip.t-dialin.net) |
| 09:26.13 | *** join/#storm vvinet (n=vince@modemcable101.133-202-24.mc.videotron.ca) |
| 12:08.30 | *** join/#storm niemeyer (n=niemeyer@200-138-37-135.ctame705.dsl.brasiltelecom.net.br) |
| 15:41.57 | *** join/#storm shaunm (n=shaunm@proxyserver.wolfram.com) |
| 16:18.43 | *** join/#storm vvinet (n=vince@24.202.133.101) |
| 17:33.38 | *** join/#storm jukart (n=jukart@d91-128-122-124.cust.tele2.at) |
| 17:39.44 | *** join/#storm tchough (n=tc@cpe-66-68-103-215.austin.res.rr.com) |
| 17:41.14 | tchough | i've got a storm object that needs to access data in a non-storm object. the data is completely run-time dependent and it does not make sense to store it in a database. how can i add a reference to this data (or the non-storm object that contains it) in my storm object? |
| 17:41.53 | tchough | normally i would use a constructor, but since this data is run-time dependent and the constructor is not called when an object is loaded, that is not an option. i don't think the __storm_loaded__ hook will work either since it cannot accept parameters. |
| 17:43.36 | tchough | global variables would be another possible solution, but i think there's probably a better solution out there that i haven't thought of. |
| 17:45.19 | therve | tchough: there is trick: constructos is (generally) not called when loading the object from the database |
| 17:45.32 | therve | s/constructos/constructor |
| 17:47.36 | tchough | therve: yes, i understand that the workaround for the is to use the __storm_loaded__ hook instead, but unless there is a way to get the hook to accept arguments, i don't think that will solve my problem |
| 17:48.10 | mzz | just use a method (which could end up returning a cached attribute)? |
| 17:48.18 | mzz | or am I misunderstanding what you're trying to do? |
| 17:49.22 | mzz | iiuc you have to first pull the object out of the store, and then pass extra runtime-dependant arguments to be able to construct your extra data |
| 17:49.33 | therve | tchough: I was not talking about __storm_loaded__ |
| 17:49.47 | therve | oh ok |
| 17:50.09 | therve | tchough: I guess you need some kind of globals |
| 17:50.15 | therve | a registry or something |
| 17:50.16 | tchough | mzz: yes, that pretty much sums it up |
| 17:51.50 | tchough | therve: yes, globals are the solution i'm gravitating towards now, but i was hoping not to have to go down that road |
| 17:53.07 | therve | tchough: fwiw, in zope we use utilities to achieve that |
| 17:54.23 | tchough | therve: how do you mean? |
| 17:55.03 | therve | tchough: well Zope utilities are some kind of configurable globals |
| 17:56.12 | therve | and we use Storm in Zope, which may be the info you're missing |
| 17:56.28 | tchough | therve: ah, i see |
| 18:41.33 | *** join/#storm jukart (n=jukart@d91-128-122-124.cust.tele2.at) |
| 20:16.30 | *** join/#storm vvinet (n=vince@modemcable101.133-202-24.mc.videotron.ca) |
| 21:13.33 | *** join/#storm thumper (n=quassel@125-236-193-95.adsl.xtra.co.nz) |
| 23:39.24 | *** join/#storm vvinet (n=vince@modemcable101.133-202-24.mc.videotron.ca) |