| *** niemeyer has quit IRC | 00:00 | |
| *** bradb is now known as bradb-out | 00:09 | |
| *** jinty has quit IRC | 00:11 | |
| *** BjornT has quit IRC | 00:12 | |
| *** dobee has quit IRC | 00:14 | |
| *** timte has quit IRC | 00:44 | |
| *** dhuber has quit IRC | 01:02 | |
| *** bcsaller has quit IRC | 01:04 | |
| *** ignas has joined #zope3-dev | 01:19 | |
| *** J1m has quit IRC | 01:25 | |
| *** hazmat has joined #zope3-dev | 01:26 | |
| *** jhauser_ has quit IRC | 01:32 | |
| *** SureshZ has left #zope3-dev | 01:33 | |
| *** projekt01 has joined #zope3-dev | 02:36 | |
| *** yota has quit IRC | 02:49 | |
| *** RaFromBRC is now known as RaFromBRC|afk | 03:05 | |
| *** d2m has quit IRC | 03:19 | |
| *** stub has joined #zope3-dev | 03:52 | |
| *** RaFromBRC|afk has quit IRC | 03:53 | |
| *** bradb-out is now known as bradb-away | 04:13 | |
| *** projekt01 has quit IRC | 05:25 | |
| *** SureshZ has joined #zope3-dev | 05:31 | |
| *** MiUlEr has joined #zope3-dev | 06:39 | |
| *** SureshZ has left #zope3-dev | 07:23 | |
| *** bskahan has joined #zope3-dev | 08:06 | |
| *** hazmat has quit IRC | 08:45 | |
| *** bskahan has quit IRC | 08:55 | |
| *** timte has joined #zope3-dev | 09:04 | |
| *** d2m has joined #zope3-dev | 09:16 | |
| *** BjornT has joined #zope3-dev | 09:19 | |
| *** SteveA_ has quit IRC | 09:30 | |
| *** guido_g has joined #zope3-dev | 09:34 | |
| *** jhauser has joined #zope3-dev | 09:44 | |
| *** philiKON has quit IRC | 09:54 | |
| *** timte has quit IRC | 10:07 | |
| *** hazmat has joined #zope3-dev | 10:07 | |
| *** yota has joined #zope3-dev | 10:18 | |
| *** tarek has joined #zope3-dev | 10:34 | |
| *** jinty has joined #zope3-dev | 11:07 | |
| *** jhauser_ has joined #zope3-dev | 11:15 | |
| *** lunatik has joined #zope3-dev | 11:18 | |
| *** jhauser has quit IRC | 11:27 | |
| *** sashav has joined #zope3-dev | 11:28 | |
| *** lunatik has left #zope3-dev | 11:35 | |
| *** hdima has joined #zope3-dev | 11:37 | |
| *** mgedmin has joined #zope3-dev | 11:59 | |
| *** philiKON has joined #zope3-dev | 12:00 | |
| hdima | '/++etc++process' doesn't work for virtual hosts | 12:02 |
|---|---|---|
| hdima | Is it safe to add 'if context is None or ...' at line 50 in 'z.a.traversing.browser.absoluteurl'? | 12:05 |
| *** MiUlEr has quit IRC | 12:19 | |
| *** jinty has quit IRC | 12:35 | |
| *** SteveA has joined #zope3-dev | 12:48 | |
| *** ignas_ has joined #zope3-dev | 13:23 | |
| *** philiKON has quit IRC | 13:26 | |
| *** mikka__ has joined #zope3-dev | 13:27 | |
| mikka__ | hello! | 13:27 |
| mikka__ | I have little problem with sandbox version of Zope3 | 13:28 |
| *** projekt01 has joined #zope3-dev | 13:29 | |
| mikka__ | I had no problems creating it | 13:29 |
| mikka__ | but every change I make to it is not persisted after server reboot | 13:29 |
| *** SteveA has quit IRC | 13:44 | |
| *** SteveA has joined #zope3-dev | 13:46 | |
| *** Aiste has joined #zope3-dev | 13:46 | |
| *** hazmat has quit IRC | 14:10 | |
| *** JZ_ has joined #zope3-dev | 14:20 | |
| *** bskahan has joined #zope3-dev | 14:31 | |
| *** faassen has joined #zope3-dev | 14:35 | |
| srichter | mikka__: what changes do you refer to? | 14:41 |
| *** JZ_ is now known as JZ | 14:51 | |
| *** mikka__ has quit IRC | 15:17 | |
| srichter | hdima: I think that process should not have a location; I am surprised, though, that it works without virtual hosts | 15:25 |
| srichter | I think I agree with your bug fix | 15:25 |
| srichter | so you are good to go | 15:25 |
| srichter | make sure to write a test as well | 15:26 |
| srichter | thanks! | 15:26 |
| *** lunatik has joined #zope3-dev | 15:26 | |
| hdima | It works simple because request.getVirtualHostRoot() returns None | 15:26 |
| hdima | Ok | 15:26 |
| *** lunatik has left #zope3-dev | 15:28 | |
| *** the|hidden has quit IRC | 15:36 | |
| *** zagy has quit IRC | 15:36 | |
| *** zagy has joined #zope3-dev | 15:36 | |
| *** SteveA has quit IRC | 15:38 | |
| *** SteveA has joined #zope3-dev | 15:52 | |
| *** the|hidden has joined #zope3-dev | 15:53 | |
| *** bradb-away is now known as bradb | 16:00 | |
| *** MiUlEr has joined #zope3-dev | 16:12 | |
| *** SureshZ has joined #zope3-dev | 16:23 | |
| *** bskahan has quit IRC | 16:25 | |
| bob2 | is there any standard code/idiom out there for writing out File's to disk? | 16:39 |
| *** tarek has quit IRC | 16:42 | |
| srichter | bob2: you have to be more specific | 16:44 |
| bob2 | so, I have some classes that inherit from File, and sometimes I need to write them out to disk | 16:45 |
| bob2 | (File's containing html, generating some static pages, basically) | 16:45 |
| bob2 | so I guess the only mildly hard bit is finding out their path in the zope instance | 16:45 |
| *** bska|mobile has joined #zope3-dev | 16:45 | |
| srichter | well, I think the var directory is known as a global somewhere | 16:47 |
| srichter | or your container should be a special one that knows the root directory of the files | 16:47 |
| bob2 | hm, I mean "virtual path to the object" | 16:47 |
| srichter | well, what are you trying to do? | 16:48 |
| bob2 | I guess I mean the url of the File object | 16:49 |
| bob2 | I'm trying to put it at the same point in the filesystem as it appears in the zope object tree | 16:50 |
| bob2 | and I know my vocabulary is shot at the moment, my apoligies | 16:50 |
| srichter | well, then | 16:52 |
| srichter | the best would be to have a special folder | 16:52 |
| srichter | that declares the root on the filesystem | 16:53 |
| bob2 | hmm | 16:53 |
| bob2 | the translation isn't the problem, I'm more trying to find the url to an object, given that object | 16:54 |
| srichter | an object is located in a folder in the ZODB | 16:57 |
| srichter | so it has a definite location | 16:57 |
| srichter | of that object knows about the path of the file in the FS, you have all the info you need | 16:57 |
| bob2 | hm, I guess I need to duplicate it when the object is created, then | 16:58 |
| *** stub has quit IRC | 16:58 | |
| *** bska|mobile has quit IRC | 16:59 | |
| *** bskahan has joined #zope3-dev | 16:59 | |
| *** J1m has joined #zope3-dev | 17:09 | |
| *** sashav has quit IRC | 17:11 | |
| *** lunatik has joined #zope3-dev | 17:15 | |
| *** JZ has quit IRC | 17:27 | |
| *** hdima has quit IRC | 17:27 | |
| bob2 | hm, which attribute is the "name" of an object stored in? | 17:31 |
| mgedmin | __name__ | 17:31 |
| mgedmin | see ILocation | 17:32 |
| bob2 | ah, thank you | 17:32 |
| bob2 | is there a general method to find where in the hierarchy an interface is? | 17:34 |
| bob2 | I usually just google for "IFoo zope3" | 17:34 |
| J1m | grep | 17:36 |
| J1m | tags | 17:36 |
| bob2 | ah, good point | 17:36 |
| J1m | There is mostly a method to the madness. | 17:36 |
| J1m | So after you get some experience, you'll probably be able to guess where things are much of the time. | 17:36 |
| bob2 | yeah, I'm getting better at guessing where they are | 17:36 |
| *** lunatik has left #zope3-dev | 17:39 | |
| *** guido_g has quit IRC | 17:40 | |
| *** philiKON has joined #zope3-dev | 17:53 | |
| *** zagy has quit IRC | 17:56 | |
| *** anguenot has joined #zope3-dev | 18:00 | |
| *** MiUlEr has quit IRC | 18:14 | |
| *** MiUlEr has joined #zope3-dev | 18:16 | |
| *** ignas_ has quit IRC | 18:43 | |
| *** d2m has quit IRC | 18:59 | |
| *** regebro has joined #zope3-dev | 19:07 | |
| *** hazmat has joined #zope3-dev | 19:38 | |
| *** ignas_ has joined #zope3-dev | 19:42 | |
| bob2 | hm, so not all objects have __name__ | 19:43 |
| *** jinty has joined #zope3-dev | 19:48 | |
| *** bskahan has quit IRC | 19:53 | |
| bob2 | hrm, even ones in containers | 19:56 |
| bob2 | where can I read about how objects get names? | 19:56 |
| projekt01 | See __setitem__ in SampleContainer | 19:57 |
| projekt01 | bob2, all objects where implement or provide the IContained have a __name__ attribute | 19:58 |
| bob2 | hmm | 19:59 |
| projekt01 | This __name__ get set in the __setitem__ method of a IContainer | 19:59 |
| bob2 | the name of the object being added to the container? | 19:59 |
| projekt01 | The container is responsible for the items name | 19:59 |
| bob2 | hm, right | 19:59 |
| projekt01 | Yes | 19:59 |
| bob2 | I have a two classes, one derives from File, one from Folder. in the zope3 web ui, when I add one to the other, the File has a __name__. | 20:00 |
| bob2 | but in my unit tests, the File does not have a __name__, even after being added to the container | 20:00 |
| bob2 | assuming 'directory["foo"] = file' does what I think, and adds file to the directory container | 20:01 |
| projekt01 | Directory['foo'] uses __setitem__ from IContainer | 20:01 |
| bob2 | right, so this should work | 20:02 |
| bob2 | I'll try using the super classes directly | 20:02 |
| projekt01 | You also could write Directory.__setitem__('foo', file) | 20:02 |
| projekt01 | If Directory is a object instance | 20:03 |
| projekt01 | If Directory is the class you can use: | 20:03 |
| projekt01 | Super(Directory, self).__setitem__('foo', file) | 20:03 |
| bob2 | ok, this sample program seems to me like it should print out "foo" | 20:06 |
| bob2 | from zope.app.file import File | 20:06 |
| bob2 | from zope.app.folder import Folder | 20:06 |
| bob2 | file = File() | 20:06 |
| bob2 | folder = Folder() | 20:06 |
| bob2 | folder["foo"] = file | 20:06 |
| bob2 | print file.__name__ | 20:06 |
| projekt01 | No | 20:07 |
| projekt01 | Try adding: | 20:07 |
| projekt01 | file = folder['foo'] | 20:07 |
| projekt01 | print file.__name__ | 20:07 |
| projekt01 | you reference to the file before adding to the container. | 20:08 |
| bob2 | hrm, wow | 20:08 |
| projekt01 | This doesn't work if you get a LocationProxy around the file from the container | 20:08 |
| bob2 | so that uses FileFactory to make me a new file? | 20:08 |
| bob2 | or do I need to reference it both ways before I can use it? | 20:09 |
| projekt01 | Does the File class implement IContained? | 20:10 |
| bob2 | hrm, no | 20:11 |
| *** MiUlEr has quit IRC | 20:11 | |
| projekt01 | Does this work for you: print folder["foo"].__name__ | 20:11 |
| bob2 | yes | 20:11 |
| projekt01 | Ok, then if you get the object form the container you get also a LocationProxy arround the object | 20:12 |
| bob2 | ah | 20:13 |
| projekt01 | this proxy contains the name and not the object itself | 20:13 |
| bob2 | hrm, how do I do-proxy it? | 20:13 |
| projekt01 | you mean remove proxy? | 20:14 |
| projekt01 | or add proxy | 20:14 |
| bob2 | er, "de-proxy", remove it | 20:14 |
| bob2 | so I get the object back | 20:14 |
| projekt01 | from zope.proxy import getProxiedObject | 20:14 |
| projekt01 | Sorry I have to go now, I'm back later. Hope that helps a little bit. | 20:15 |
| bob2 | it did, thank you very much | 20:15 |
| bob2 | is this sort of level of question approriate for the zope3-users or zope3-dev list? | 20:19 |
| *** neder-zzz is now known as nederhoed | 20:25 | |
| *** hazmat has quit IRC | 20:27 | |
| *** faassen has quit IRC | 20:27 | |
| *** jinty has quit IRC | 20:29 | |
| bob2 | should I make my classes implement IContained? | 20:32 |
| nederhoed | if you want to restrict what containers, you could implement IContained | 20:33 |
| bob2 | ah | 20:33 |
| nederhoed | I think there is something written in Stephan Richter's Zope3 Dev book | 20:33 |
| bob2 | but to just be,er, Contained, I don't need to? | 20:33 |
| bob2 | hm, I thought so, too, but I can't seem to find it | 20:34 |
| nederhoed | hum, I have to rethink that | 20:34 |
| srichter | bob2: findinf ifaces: you can also always use the API doctool | 20:34 |
| bob2 | oh, of course, I forgot about that | 20:34 |
| srichter | bob2: you should always get an object's name using zapi.getName(object) | 20:35 |
| bob2 | ah, IContained is mentioned in the messageboard interface discussion | 20:35 |
| nederhoed | indeed | 20:36 |
| srichter | (not all objects have to directly implement IContained, but only require an adapter to it | 20:36 |
| srichter | all your content objects should implement IContained | 20:37 |
| srichter | or at least ILocation | 20:37 |
| bob2 | hrm, using zope.app.zapi.getName tells me that it can't adapt my objects to zope.app.traversing.interfaces.IPhysicallyLocatable | 20:38 |
| srichter | that's a good rule of thumb, which I have never not used :-) | 20:38 |
| bob2 | hm, I guess this is a result of what you just suggested? | 20:38 |
| srichter | make it an IContained, then add it to a container | 20:38 |
| srichter | it should work | 20:38 |
| srichter | yes | 20:38 |
| srichter | oh yeah, of course it is much easier to just inherit from the Contained class | 20:39 |
| srichter | this way you don't have to worry about the implementation | 20:39 |
| bob2 | hm, yeah, I thoguht inheriting from File would give me all this | 20:39 |
| srichter | which File did you inherit? | 20:40 |
| bob2 | zope.app.file.file.File | 20:40 |
| srichter | geez, the zope.app.file.file.File class is really old | 20:40 |
| bob2 | ah | 20:40 |
| srichter | it has not been modernized | 20:40 |
| srichter | but the data code is good of course | 20:41 |
| bob2 | is there another simple Contained class I could inherit from? | 20:41 |
| bob2 | hrm, why is there zope.app.file.file.File and zope.app.file.File? | 20:41 |
| J1m | New containers generally subclass BTreeContainer. | 20:42 |
| bob2 | I'm more looking for a base "containee" class, this is a leaf node object | 20:43 |
| srichter | bob2: zope.app.file.File is just a link to the other one | 20:48 |
| srichter | it's suppose to make imports shorter | 20:48 |
| bob2 | ah | 20:53 |
| J1m | bob2, maybe you want zope.app.container.contained.Contained ;) | 20:54 |
| bob2 | ah | 20:54 |
| J1m | Depending what you want to do | 20:54 |
| J1m | which is unclear :) | 20:54 |
| *** jinty has joined #zope3-dev | 20:55 | |
| anguenot | Hi all. got a question about how to deal with component registration dependencies | 21:09 |
| anguenot | The example is with the catalog for instance | 21:09 |
| anguenot | it depends of the uidutil | 21:09 |
| anguenot | but if theis utility is not here I can create my catalog | 21:10 |
| anguenot | but It will crash as system error if I try to register it | 21:10 |
| anguenot | because getUtility() is used within the internals of the catalog component | 21:10 |
| anguenot | without traping exceptions | 21:11 |
| J1m | so far so good | 21:11 |
| anguenot | Shoud the catalog trap tjhe ComponentLookup exceptions (or use queryUtility()) ? or should simply we *not* allow the creation of the catalog itself ? | 21:12 |
| anguenot | because it's useless without the registration of the uidtool anyway | 21:12 |
| anguenot | ? | 21:12 |
| J1m | It shouldn't silently ignore the problem. | 21:12 |
| J1m | Perhaps in it's UI, it should provide some diagnosis. | 21:12 |
| anguenot | i'm fine with this | 21:12 |
| *** regebro has quit IRC | 21:12 | |
| anguenot | yup | 21:13 |
| anguenot | such as not proposing the registration | 21:13 |
| anguenot | on the registration form | 21:13 |
| J1m | perhaps | 21:13 |
| J1m | This is fairly generic code though. | 21:13 |
| J1m | You would need to provide a custom registration view for it. | 21:13 |
| anguenot | I was more thinking about registration deps | 21:14 |
| anguenot | for a utility | 21:14 |
| anguenot | that you wanna register | 21:14 |
| J1m | Of course, it would be sort of nice if there was some kind of more general prerequisite framework. | 21:14 |
| srichter | I think there is definitely a place for solving this problem generically | 21:14 |
| anguenot | It means that the utility would be aware about the fact that he needs certain utilities and or services for being able to be registered | 21:15 |
| srichter | I think the prerequisites should be more general | 21:16 |
| anguenot | can you explain this ? | 21:17 |
| srichter | i.e. every pre-requisite is a callable that has to return True | 21:17 |
| srichter | for example | 21:17 |
| srichter | the callable's doc string could be used as explanatory textvery similar to how generations work | 21:17 |
| srichter | if we want to be more fancy, we could have PreRequisite objects that can even offer to fulfill the prerequisite | 21:18 |
| srichter | so you get an overview of all the prereqs and it tells you which are fulfilled and which are not | 21:19 |
| * mgedmin idly thinks that docstrings and i18n do not mix well | 21:19 | |
| srichter | if a prerequisite can fulfill itself, you can check it and click "Fulfill" or so | 21:19 |
| anguenot | yups would rock :) | 21:19 |
| anguenot | ok | 21:19 |
| srichter | mgedmin: probably not, so a prerequisite object would be more appropriate | 21:20 |
| anguenot | and do you see the association in betwee, the prerequiste object and the object itself ? | 21:20 |
| anguenot | how | 21:20 |
| srichter | it could be an adapter, for example | 21:21 |
| anguenot | ok | 21:22 |
| srichter | even better a subscriber | 21:22 |
| srichter | because you want several of those subscribers for a given object | 21:23 |
| srichter | I think that would be very scalable, since one prerequisite might have other prerequisites | 21:23 |
| anguenot | right | 21:23 |
| srichter | doing this in a subscriber model would allow for a full prerequisite graph (eventually, as in later) | 21:23 |
| anguenot | We should write something about it . | 21:24 |
| srichter | we should solve the simple case first and not overdesign | 21:24 |
| anguenot | ok thanks Stephan. | 21:25 |
| srichter | you are welcome | 21:25 |
| *** hazmat has joined #zope3-dev | 21:28 | |
| *** douglasc has joined #zope3-dev | 21:31 | |
| *** jinty has quit IRC | 21:32 | |
| nederhoed | is it true that if I have a site using, say 4 products, when creating a skin I could best create a product that contains custom views for those 4 products? | 21:32 |
| *** weaselgod has joined #zope3-dev | 21:33 | |
| *** jinty has joined #zope3-dev | 21:33 | |
| weaselgod | can someone point me to a good IRC channel for Plone based discussion? | 21:34 |
| srichter | weaselgod: no plone guys here, but try #plone | 21:35 |
| weaselgod | hmm, that channel doesn't exist, but thanks anyway | 21:36 |
| srichter | yes it does | 21:36 |
| weaselgod | oops, found it | 21:36 |
| srichter | I just tried it | 21:36 |
| weaselgod | typo :) | 21:36 |
| weaselgod | thanks | 21:36 |
| *** weaselgod has left #zope3-dev | 21:36 | |
| *** RaFromBRC has joined #zope3-dev | 21:42 | |
| *** mgedmin has quit IRC | 21:50 | |
| *** Aiste has quit IRC | 21:51 | |
| nederhoed | someone? | 21:51 |
| srichter | huh? | 21:52 |
| *** lunatik has joined #zope3-dev | 21:53 | |
| *** lunatik has left #zope3-dev | 21:54 | |
| *** anguenot has quit IRC | 21:54 | |
| *** jhauser has joined #zope3-dev | 21:57 | |
| *** ignas_ has quit IRC | 21:58 | |
| *** jhauser_ has quit IRC | 22:01 | |
| *** hazmat has quit IRC | 22:04 | |
| *** douglasc has quit IRC | 22:18 | |
| nederhoed | my question was: is it true that if I have a site using, say 4 products, when creating a skin I could best create a product that contains custom views for those 4 products? | 22:39 |
| nederhoed | and I also wonder if I should share an instance for multiple sites, or if I should run multiple instances parallel | 22:40 |
| *** RaFromBRC has quit IRC | 22:44 | |
| *** nederhoed has quit IRC | 22:46 | |
| *** nisha_cgx has joined #zope3-dev | 22:57 | |
| *** nisha_cgx has quit IRC | 23:02 | |
| *** nederhoed has joined #zope3-dev | 23:02 | |
| *** d2m has joined #zope3-dev | 23:12 | |
| *** nederhoed has quit IRC | 23:17 | |
| *** ignas_ has joined #zope3-dev | 23:30 | |
| *** ignas has quit IRC | 23:42 | |
| *** ignas_ has quit IRC | 23:42 | |
| *** jinty has quit IRC | 23:42 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!