| J1m | I don't know | 00:00 |
|---|---|---|
| J1m | I'm not in your situation, so It's hard to say. | 00:00 |
| J1m | I'm a bit surprised at your symptoms. | 00:01 |
| mgedmin | fair enough | 00:01 |
| J1m | I still suggest trying to remove the utility service. | 00:01 |
| J1m | Hm | 00:02 |
| J1m | That's not going to work | 00:02 |
| J1m | Waaaa | 00:02 |
| J1m | Undo is my friend. :) | 00:03 |
| J1m | OK, here's what I suggest. | 00:03 |
| J1m | Get to the utilities object with a Python prompt. | 00:03 |
| J1m | Do you know how to do that? | 00:03 |
| mgedmin | I'm not sure | 00:04 |
| mgedmin | something like zopectl debug, no? | 00:04 |
| J1m | Yup, that's the easiest way. | 00:05 |
| J1m | It's worth learning how to do. | 00:05 |
| J1m | You could probably just repair your Utilities object by hand. | 00:05 |
| J1m | Oh wait | 00:06 |
| J1m | Is this in the root of your database? | 00:06 |
| mgedmin | yes | 00:07 |
| J1m | OK, here's what to do. | 00:07 |
| J1m | just aa sec | 00:08 |
| * mgedmin looks at dir(root.getSiteManager()['default']['Utilities']) in the debugger prompt | 00:09 | |
| J1m | Ok, add a new utilities service and make it active | 00:10 |
| J1m | At that point, zope will be unhappy because some utilities will be absent | 00:11 |
| J1m | restart zope | 00:11 |
| J1m | at that point, you'll have a new utility service with the basic utilities you need. | 00:11 |
| J1m | :) | 00:11 |
| mgedmin | all that without removing the old utilities service, right? | 00:12 |
| J1m | right | 00:12 |
| J1m | At that point, it won't be used anymore | 00:12 |
| *** Jim7J1AJH has quit IRC | 00:12 | |
| * mgedmin tries | 00:14 | |
| mgedmin | ok, I have a brand new utilities service with four utilities | 00:14 |
| mgedmin | and two copies of all essential utilities ;) | 00:15 |
| J1m | You can remove their registrations and then remove them | 00:15 |
| * mgedmin removes all disabled registrations | 00:16 | |
| J1m | yup | 00:16 |
| mgedmin | great, I could add and register a Principal Folder now | 00:18 |
| mgedmin | thanks | 00:18 |
| J1m | Yay | 00:18 |
| mgedmin | I wonder what was wrong | 00:18 |
| *** Jim7J1AJH has joined #zope3-dev | 00:18 | |
| J1m | A utility service is an adapter registry, which is like a mapping from (iface,name) -> collection of components | 00:19 |
| J1m | Even though the collection of components was empty, the key was still there | 00:19 |
| mgedmin | ah | 00:21 |
| mgedmin | I see | 00:21 |
| *** mgedmin has quit IRC | 00:33 | |
| *** Aiste has quit IRC | 01:02 | |
| *** alga has quit IRC | 01:02 | |
| *** srichter has quit IRC | 01:19 | |
| *** tvon has joined #zope3-dev | 01:51 | |
| *** J1m has quit IRC | 02:17 | |
| *** Damascene has quit IRC | 02:20 | |
| *** srichter has joined #zope3-dev | 02:30 | |
| *** ChanServ sets mode: +o srichter | 02:41 | |
| *** bskahan has quit IRC | 02:49 | |
| *** Damascene has joined #zope3-dev | 02:51 | |
| *** hazmat has quit IRC | 04:00 | |
| *** hazmat has joined #zope3-dev | 04:00 | |
| *** bskahan has joined #zope3-dev | 04:05 | |
| *** mexiKON has joined #zope3-dev | 04:15 | |
| *** philiKON has quit IRC | 04:25 | |
| *** bskahan has quit IRC | 05:11 | |
| *** `anthony has quit IRC | 05:25 | |
| *** hazmat has quit IRC | 05:30 | |
| *** `anthony has joined #zope3-dev | 05:50 | |
| *** tav|offl1ne has quit IRC | 06:26 | |
| *** tvon has quit IRC | 06:26 | |
| *** bradb has quit IRC | 06:26 | |
| *** tvon has joined #zope3-dev | 06:27 | |
| *** tav|offl1ne has joined #zope3-dev | 06:27 | |
| *** bradb has joined #zope3-dev | 06:27 | |
| *** sashav has joined #zope3-dev | 06:40 | |
| *** sashav has quit IRC | 07:25 | |
| *** sashav has joined #zope3-dev | 08:58 | |
| *** sashav has quit IRC | 09:02 | |
| *** sashav has joined #zope3-dev | 09:03 | |
| *** sashav_ has joined #zope3-dev | 09:08 | |
| *** SteveA has joined #zope3-dev | 09:11 | |
| *** SteveA_ has joined #zope3-dev | 09:13 | |
| *** stub has joined #zope3-dev | 09:14 | |
| *** apauley has joined #zope3-dev | 09:20 | |
| *** SteveA has quit IRC | 09:30 | |
| *** jhauser_ has quit IRC | 09:46 | |
| *** `anthony has quit IRC | 09:51 | |
| *** SteveA_ is now known as SteveA | 10:21 | |
| *** sashav has quit IRC | 10:25 | |
| *** d2m has quit IRC | 10:42 | |
| *** Aiste has joined #zope3-dev | 10:49 | |
| *** SteveA has quit IRC | 10:58 | |
| *** d2m has joined #zope3-dev | 11:00 | |
| *** tarek has joined #zope3-dev | 11:11 | |
| *** hdima has joined #zope3-dev | 11:12 | |
| *** SteveA has joined #zope3-dev | 11:15 | |
| *** MalcolmC has joined #zope3-dev | 11:27 | |
| *** mexiKON is now known as philiKON | 12:20 | |
| *** kinder has joined #zope3-dev | 12:23 | |
| *** mkerrin has joined #zope3-dev | 12:27 | |
| *** BjornT has quit IRC | 12:29 | |
| * VladDrac 's still fighting zope3 | 12:30 | |
| VladDrac | for some reason, my registered utility gets lost somewhere | 12:30 |
| VladDrac | I'm parsing zcml in two stages (which seems to work fine, new directives are accepted in the second stage), but my utility is lost in the second stage | 12:30 |
| *** SteveA_ has joined #zope3-dev | 12:35 | |
| *** SteveA has quit IRC | 12:38 | |
| *** SteveA_ is now known as SteveA | 12:39 | |
| philiKON | VladDrac, why are you parsing in stages? | 12:51 |
| philiKON | VladDrac, the best way is to have one ZCML tree that gets parsed once | 12:51 |
| SteveA | note that zcml is processed in two phases | 12:51 |
| philiKON | yup | 12:52 |
| VladDrac | phil: I suspected that. 2 stages makes more sense in my case | 12:52 |
| VladDrac | my app 'uses' z3 stuff in stead of my app being a component in z3 | 12:52 |
| philiKON | well, what i'm saying is: do you *need* two stages, or could you just do 2 major imports in the same zcml tree | 12:52 |
| VladDrac | (and five claims you can load multiple zcml files) | 12:52 |
| philiKON | where does five claim that? | 12:53 |
| VladDrac | def process(file, execute=True, package=None): | 12:53 |
| VladDrac | """Process a ZCML file. | 12:53 |
| VladDrac | Note that this can be called multiple times, unlike in Zope 3. This | 12:53 |
| VladDrac | is needed because in Zope 2 we don't (yet) have a master ZCML file | 12:53 |
| VladDrac | which can include all the others. | 12:53 |
| VladDrac | """ | 12:53 |
| VladDrac | (zcml.py) | 12:53 |
| philiKON | oh yes, now we do :) | 12:53 |
| philiKON | we have a site.zcml in Five now as well | 12:53 |
| philiKON | that comment should be updated | 12:54 |
| philiKON | don't remember what problems they were, but we ran into them when we had not a single tree of zcml in five | 12:54 |
| VladDrac | ah ok | 12:55 |
| VladDrac | I actually tried a single tree of zcml files/imports | 12:55 |
| VladDrac | I ran into different problems then, but if that's the only supported way, that's what I'll do (and I'll bug you with the new issues I run into :) | 12:55 |
| philiKON | k | 12:56 |
| *** J1m has joined #zope3-dev | 13:20 | |
| *** SteveA has quit IRC | 13:27 | |
| *** J1m has quit IRC | 13:28 | |
| *** gintas has joined #zope3-dev | 13:28 | |
| *** Theuni has joined #zope3-dev | 13:36 | |
| *** mkerrin has quit IRC | 13:37 | |
| *** SteveA has joined #zope3-dev | 13:39 | |
| *** J1m has joined #zope3-dev | 13:48 | |
| *** hdima has quit IRC | 13:51 | |
| *** hdima has joined #zope3-dev | 13:52 | |
| VladDrac | still similar issues | 13:56 |
| VladDrac | using all kinds of magic to register a utility from zcml and use the utility using new zcml directives (which works) | 13:56 |
| VladDrac | then, when the zcml parsing has been done, I'm trying to access the same utility in the same way as I did in the directives -> No luck (queryUtility results in None) | 13:57 |
| VladDrac | hmm wait | 14:00 |
| VladDrac | it works | 14:00 |
| VladDrac | yay! | 14:00 |
| VladDrac | (changing the order of some zcml directives) | 14:01 |
| VladDrac | it even works in two steps now! | 14:01 |
| * J1m has no idea why VladDrac has had so much difficulty | 14:02 | |
| VladDrac | neither do I | 14:02 |
| VladDrac | but it's me usually | 14:02 |
| *** hdima has quit IRC | 14:03 | |
| * J1m suspects that, if VladDrac is really using components without Zope, then he should probably not be using zcml. | 14:03 | |
| *** hdima has joined #zope3-dev | 14:03 | |
| VladDrac | ok, it's not related to zcml order, it's related to package stuff - fully qualifying my interface (foo.bar.IInterface instead of IInterface) | 14:03 |
| J1m | ZCML is important for an app server with pluggable applications, but probably gets in the way of simpler applications. | 14:03 |
| J1m | ah | 14:03 |
| J1m | fukky-qualified imports are critical in Python, due to a regrettable import design flaw | 14:04 |
| J1m | fully-qualified imports are critical in Python, due to a regrettable import design flaw | 14:04 |
| VladDrac | yeah | 14:05 |
| VladDrac | I did: from interfaces import IMyInterface, from mypkg.interfaces import IMyInterface works (so does passing mypkg.interfaces.IMyInterface) | 14:06 |
| J1m | yup | 14:07 |
| J1m | As a matter of style, you should never do relative imports | 14:07 |
| J1m | This is a shame | 14:07 |
| J1m | There's an outstanding pep that will make reletive imports safe | 14:07 |
| J1m | I wish it was done for 2.4 | 14:07 |
| SteveA | darn | 14:08 |
| SteveA | i thought it was going to be | 14:09 |
| SteveA | a while ago | 14:09 |
| J1m | Nobody had time | 14:09 |
| J1m | What's worse, I heard it just needed tests. | 14:09 |
| J1m | It still needs someone to do it for 2.5. | 14:10 |
| *** apauley has quit IRC | 14:20 | |
| *** regebro has joined #zope3-dev | 14:27 | |
| *** srichter has quit IRC | 14:30 | |
| *** `anthony has joined #zope3-dev | 14:33 | |
| *** J1m has quit IRC | 14:38 | |
| *** stub has left #zope3-dev | 14:44 | |
| *** foranytoc has joined #zope3-dev | 14:48 | |
| *** stub has joined #zope3-dev | 14:51 | |
| *** sashav_ has quit IRC | 15:01 | |
| *** SteveA has quit IRC | 15:06 | |
| *** SteveA has joined #zope3-dev | 15:09 | |
| *** projekt01 has joined #zope3-dev | 15:22 | |
| *** foranytoc has quit IRC | 15:24 | |
| *** faassen has joined #zope3-dev | 15:28 | |
| *** srichter has joined #zope3-dev | 15:33 | |
| projekt01 | Jim, Do you have time for a question? (roger ineichen) | 15:36 |
| *** ChanServ sets mode: +o srichter | 15:37 | |
| srichter | projekt01: Jim is not here; he will be probably online within an hour | 15:37 |
| projekt01 | Ok, thanks | 15:39 |
| *** SteveA has quit IRC | 16:04 | |
| *** SteveA has joined #zope3-dev | 16:06 | |
| *** BjornT has joined #zope3-dev | 16:07 | |
| *** dlk has joined #zope3-dev | 16:26 | |
| *** alga has joined #zope3-dev | 16:28 | |
| tarek | hello, i was wondering if it could be interesting to integrate in the zope 3 mail sender utility high levels functionnalities | 16:29 |
| philiKON | what would that be? | 16:29 |
| tarek | i am coding a webmail based on five, and i have a utility that deals with mail sending : | 16:29 |
| philiKON | note that zope3 has such utilities, sendmail and smtp delivery and queued or direct senders | 16:31 |
| *** stub has quit IRC | 16:35 | |
| tarek | ok, the only difference I guess is that i create a email.Message instance and gives the user the ability to add attached files | 16:36 |
| *** stub has joined #zope3-dev | 16:37 | |
| philiKON | tarek, i really don't know what you need to do, but using email.Message and each one of the zope 3 sender/delivery utilities works very well | 16:37 |
| philiKON | (except for stupid encoding issues in email.Message, but that's a different story) | 16:38 |
| alga | the main feature of queued Zope 3 mail delivery is that it is transactional | 16:38 |
| philiKON | yes, it's very handy that way | 16:39 |
| philiKON | i wonder if it can plug into zope 2.7's transactions? | 16:39 |
| alga | I don't see why not | 16:39 |
| philiKON | i don't know too much about datamanagers and such | 16:39 |
| alga | only the data manager callbacks have different names | 16:39 |
| philiKON | is it compatible with zope 2.7 out-of-the-box? | 16:39 |
| alga | I doubt it | 16:40 |
| philiKON | ah | 16:40 |
| philiKON | but the adoption would be trivial, i guess? | 16:40 |
| alga | probably | 16:40 |
| tarek | ok thanks for the informations, i'll implement the queued mail delivery thing | 16:41 |
| *** hdima has quit IRC | 16:45 | |
| *** J1m has joined #zope3-dev | 16:48 | |
| *** BjornT has quit IRC | 16:49 | |
| *** dlk has quit IRC | 16:54 | |
| projekt01 | Jim, how should the authentication act with utilities of parent site's like the search plugins? | 16:59 |
| *** niemeyer has joined #zope3-dev | 17:13 | |
| J1m | The authentication's getQueriable's method is supposed to delegate to authentication utilities above it. | 17:13 |
| J1m | I think that what's happening is that the parent authentication utility is searching for utilities in the proginal site. | 17:14 |
| J1m | The issue isn't the prefix, it's the utility name for the plugins | 17:15 |
| *** mgedmin has joined #zope3-dev | 17:15 | |
| projekt01 | Yes, I try to solve it right now | 17:16 |
| J1m | The current version of getQueriables is: | 17:16 |
| J1m | def getQueriables(self): | 17:17 |
| J1m | for searcher_id in self.searchers: | 17:17 |
| J1m | searcher = queryUtility(IPrincipalSearchPlugin, searcher_id) | 17:17 |
| J1m | yield searcher_id, searcher | 17:17 |
| J1m | It probably should be: | 17:17 |
| J1m | def getQueriables(self): | 17:18 |
| J1m | for searcher_id in self.searchers: | 17:18 |
| J1m | searcher = queryUtility(IPrincipalSearchPlugin, searcher_id, | 17:18 |
| J1m | context=self) | 17:18 |
| J1m | yield searcher_id, searcher | 17:18 |
| J1m | 17:18 | |
| projekt01 | Yes, I tried it like: | 17:18 |
| projekt01 | def getQueriables(self): | 17:18 |
| projekt01 | for searcher_id in self.searchers: | 17:18 |
| projekt01 | searcher = queryUtility(IPrincipalSearchPlugin, searcher_id, context=self) | 17:18 |
| projekt01 | yield searcher_id, searcher | 17:18 |
| projekt01 | It seams to be OK now | 17:18 |
| J1m | cool | 17:18 |
| projekt01 | I have to rewrite the tests now | 17:19 |
| J1m | Yup | 17:19 |
| J1m | Thanks! | 17:19 |
| projekt01 | Yup | 17:20 |
| regebro | Hmm. Have I found an implementedBy(object.__class__) bug or am I doing something wrong? | 17:27 |
| regebro | It seems to find loads and loads of interfaces (all correct I think) that are implemented, but not all... | 17:28 |
| *** SteveA has quit IRC | 17:28 | |
| regebro | object implements(IZodbEvent), and IZODBEvent subclasses ISingleEvent, that subclasses IEvent. | 17:28 |
| regebro | But IEvent never appears in the iteration. | 17:28 |
| regebro | Known problem? | 17:28 |
| *** SteveA has joined #zope3-dev | 17:31 | |
| philiKON | regebro, implementedBy isn't supposed to return base interfaces of implemented interfaces | 17:33 |
| SteveA | you want to flatten it, and iterate over that | 17:33 |
| regebro | Ah. That explains it. | 17:33 |
| philiKON | right, what SteveA says | 17:33 |
| SteveA | list(implementedBy(cls).flatten()) | 17:33 |
| regebro | OK, I'll try that. | 17:34 |
| philiKON | well, do you even need the list() in front? | 17:34 |
| philiKON | if you just iterate | 17:34 |
| srichter | no, but you see all interfaces this way | 17:34 |
| philiKON | yes | 17:34 |
| SteveA | sure. that's what i use in the debugger / interactive prompt | 17:34 |
| philiKON | yes, 'see' as in the interpeter | 17:34 |
| philiKON | if you iterate, you're fine with the iterator | 17:35 |
| regebro | 'Implements' object has no attribute 'flatten' | 17:38 |
| philiKON | flattened() | 17:39 |
| regebro | philiKON, SteveA that did the trick. Thanks. | 17:41 |
| SteveA | someone document this somewhere please! | 17:41 |
| SteveA | extra kudos points for whoever does so | 17:41 |
| philiKON | i've been wanting to setup a 'tips 'n' tricks' site for a long time now | 17:41 |
| philiKON | i suspect a simple wiki page would do it for now as well | 17:42 |
| projekt01 | How can I get the site in a doctest if I use placelesssetup.setUp? | 17:43 |
| philiKON | if you need a physical site, shouldn't you use placeful setup? | 17:43 |
| projekt01 | Argh, I need a site for search 'searchers' in PAU Readme.txt tests. | 17:44 |
| projekt01 | Is there now way for to get the site? | 17:45 |
| srichter | I think we have an FAQ, maybe we should extend it | 17:45 |
| philiKON | projekt01, a) there must be other doctests that do this b) i think placeful setup is a godo place to start looking | 17:45 |
| philiKON | like i said above | 17:45 |
| philiKON | srichter, this is really not so much a faq issue | 17:45 |
| philiKON | srichter, more of a recipe thing like zopelabs.com | 17:46 |
| philiKON | in fact, maybe we should just use zopelabs.com | 17:46 |
| philiKON | make a new category 'zope3' | 17:46 |
| J1m | Please no one use plceful setup anymore | 17:46 |
| philiKON | oh, ok | 17:46 |
| philiKON | so, enlighten us, how do you do local stuff in doctests now...custom setUps? | 17:47 |
| J1m | projekt01, see the the testing helper functions in zope.app.component.localservice | 17:48 |
| projekt01 | Ok, I will take a look at... | 17:49 |
| J1m | well, no, not there | 17:49 |
| J1m | hm | 17:49 |
| J1m | in zope.app.utility.utility see testingNextUtility | 17:50 |
| projekt01 | Ok | 17:50 |
| J1m | wrt tips | 17:50 |
| J1m | I'd really like to see tips/howtos checked into the source tree | 17:50 |
| J1m | Preferably with some naming convention that makes them easy to find. | 17:51 |
| J1m | Ideally as doctests so they stay current. :) | 17:51 |
| * mgedmin likes that idea | 17:51 | |
| J1m | I would assume that the introspection api discussed above is already documented in zope/interface/README.txt. | 17:52 |
| J1m | If it isn't, it should be. | 17:52 |
| srichter | btw, zope.app.utility.utility.testingNextUtility will move to zope.app.component.testing.testingNextUtility | 18:14 |
| philiKON | J1m, not everyone reads source code... | 18:15 |
| philiKON | and reading doctests are almost like reading source code | 18:15 |
| philiKON | s/are/is/ | 18:15 |
| J1m | No, that's not true | 18:15 |
| J1m | Or, I should say | 18:15 |
| philiKON | i wouldn't mind managing tips there, but we'd need some sort of combined presentation for newbies that are looking for answers, e.g. on the web | 18:15 |
| J1m | There's a *big* difference between implementation source code and example source code. | 18:16 |
| J1m | No one should have to read implementation source code. | 18:16 |
| J1m | Everybody should be willing and anxious to read example source code. | 18:16 |
| philiKON | ok, fair enough | 18:17 |
| J1m | If you have docs without examples, you are pretty much guaranteeing that they will become stale. | 18:17 |
| philiKON | but we should maybe think about arranging a common location for this documentation, e.g. on the web | 18:17 |
| philiKON | where people can just browse | 18:17 |
| philiKON | i agree | 18:17 |
| J1m | If you say so. | 18:17 |
| J1m | I'd rather browse the source tree *if* things are easy to find. | 18:17 |
| philiKON | same here | 18:18 |
| philiKON | but i don't see John Doe Prrogrammer do this | 18:18 |
| projekt01 | Or they can buy some nice books ;-) | 18:18 |
| J1m | Exactly | 18:18 |
| *** SteveA has quit IRC | 18:18 | |
| philiKON | John Doe Programmer installs zope x3 into /usr/local/ZopeX3-3.0.0 and is happy | 18:18 |
| philiKON | projekt01, hehe, that's what srichter and i are counting on *g* | 18:18 |
| J1m | Someday, I'd love to have a tool that assembles all of the documentation for a site into a static web site. | 18:19 |
| mgedmin | can we build browseable html documentation from all the readmes in the source tree? | 18:19 |
| *** BjornT has joined #zope3-dev | 18:19 | |
| J1m | I think we can. | 18:19 |
| philiKON | that'd be a good idea imo | 18:20 |
| J1m | And from registration information. | 18:20 |
| srichter | (one of the projects that is very high on my prototyping todo list is to assemble all README.txt files into a comprehensive help using the online system) | 18:20 |
| J1m | Heck, if apidoc included this info, one could probably just wget an apidoc server | 18:20 |
| philiKON | great | 18:20 |
| srichter | I have already ideas on how to do this | 18:20 |
| projekt01 | A (ZCML) registration overview whould be nice, ... For e.g.(ZCML and the missing adapts information in the future) | 18:22 |
| * VladDrac was thinking of building some sort of zcml browser, but now that I know how extensible zcml is I don't dare to anymore :) | 18:23 | |
| J1m | VladDrac, apidoc already is, to some extent. | 18:23 |
| * J1m wishes more people would work on apidoc | 18:23 | |
| projekt01 | Oh, a hard way to deep in...but I agree we have to commit more on apidoc | 18:24 |
| projekt01 | E.g. contextual information (provide a link to a overview of the context and all it's components, adapters, views etc) | 18:26 |
| srichter | what do you mean by "context"? | 18:27 |
| tarek | ok thanks for the informations, i'll implement the queued mail delivery thing | 18:27 |
| tarek | sorry bad window | 18:27 |
| projekt01 | Add a view like classBrowser which repports also registred views, adapters etc. now we only have interfaces and bases listed | 18:29 |
| J1m | You mean as part of the introspector? | 18:30 |
| J1m | I like that. | 18:30 |
| J1m | Note that you can go to an interface and see all of the adapters. | 18:30 |
| projekt01 | We really have to add submenues, then we can register more view_actions without to mess up the ZMI | 18:30 |
| J1m | But I like the idea of being able to see this for a class or even an instance. | 18:30 |
| projekt01 | Yes I can, but I do it to less, I like to have a quick link | 18:31 |
| J1m | We also need to be able to distinguish between adapters registered for an interface, and adapters registered for base interfaces, especially Interface and defaults | 18:31 |
| J1m | projekt01, that's for the reminder wrt submenus :) | 18:31 |
| projekt01 | Apidoc is a great tool for browse and learn about, but we need a quicker access to information | 18:32 |
| projekt01 | Jim, yup | 18:32 |
| projekt01 | Give me some hints where to start, it's on my next step(Todo) list | 18:32 |
| srichter | note that the class browser does this already | 18:32 |
| J1m | The introspetor tab should be expanded and reuse apidoc facilities | 18:32 |
| srichter | if it does not, it can be easily made to do this | 18:32 |
| J1m | srichter, but you want this for instances too | 18:33 |
| srichter | introspector should really be removed and replaced by apidoc components | 18:33 |
| srichter | J1m: yeah, it is a very simple step though | 18:33 |
| J1m | Basically, you want to see components registered for providedBy(ob) | 18:33 |
| *** SteveA has joined #zope3-dev | 18:33 | |
| srichter | I outlined it to roger in an Email or IRC before | 18:33 |
| srichter | its about 7-10 lines of code | 18:33 |
| srichter | all we need is a view that gets the class of an instance and then redirects to the correct class browser URL in API doc | 18:34 |
| projekt01 | Ok, should I refactor the classBrowser after work on authentication? | 18:34 |
| J1m | That would be great | 18:35 |
| projekt01 | Ok | 18:35 |
| J1m | But note what I said: | 18:35 |
| J1m | Basically, you want to see components registered for providedBy(ob) | 18:35 |
| projekt01 | I really like to solve the missing layer in menues | 18:35 |
| J1m | That is, the intrispector should, in addition to listing the class and interface information, show: | 18:35 |
| J1m | components registered for providedBy(ob) | 18:35 |
| J1m | This is really adapters | 18:36 |
| projekt01 | It whold be great to have ideas for submenues at this time | 18:36 |
| J1m | But I have to think about that. :) | 18:36 |
| * J1m thinks ... | 18:36 | |
| * J1m k=looks for clues in old email ... | 18:37 | |
| * J1m looks for clues in old email ... | 18:37 | |
| projekt01 | Jim, Ok that's fine, then I try to implement layers in meues without submenues, we can work on this later. | 18:37 |
| J1m | Ah | 18:40 |
| J1m | http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/AdaptersForMenuItems | 18:40 |
| J1m | This discusses submenus. | 18:40 |
| J1m | I think I still like this. | 18:40 |
| *** kinder has quit IRC | 18:40 | |
| J1m | Even though it is marked as implemented, I don't think the submenu part is implemented. | 18:41 |
| J1m | projekt01, ok? | 18:41 |
| projekt01 | Cool, I will take a look at this | 18:41 |
| J1m | The idea is very simpler. | 18:41 |
| J1m | Note that the menu system is much more pattern than software. | 18:41 |
| J1m | The idea is very simple. | 18:41 |
| J1m | The presentation code that displayes a menu has to recognize menu items that have submenus and display the submenus as appropriate. | 18:42 |
| projekt01 | Yes, I see, we will support a simply way for render submenus for old browsers or simply skins like the ZMI skin and also a way for new browsers perhaps with xml/javascript like the zmitree. | 18:45 |
| srichter | right, except that this is tricky, because none of the framework is aware of sub-menues; you also have to think about a way to represent this in ZCML and BBB | 18:45 |
| projekt01 | uhhh | 18:46 |
| *** faassen has quit IRC | 18:46 | |
| srichter | projekt01: just make sure it runs on Safari/Konqueror :-) At some point I will replace the Rotterdam XML tree by the nice static one from Philip ;-) | 18:46 |
| J1m | srichter, there is almost no framework. | 18:47 |
| J1m | A submenu is really just a menu. | 18:47 |
| J1m | There is no difference bwteeen a submenu or a menu from zcml. | 18:47 |
| projekt01 | Stefan, Yes, the Zmi should really be simple html 3.0 | 18:47 |
| srichter | but skins expect a certain output from getMenu() [or whatever it is called] | 18:47 |
| srichter | you would need to embed submenues there somehow | 18:47 |
| srichter | right now this getMenu()??? function returns a list of dictionaries | 18:48 |
| J1m | I sugest that the menuItem directive should grow a submenu attribute for specifying a submenu | 18:48 |
| J1m | so the dictionaries get an extra key | 18:49 |
| J1m | a submenu key | 18:49 |
| projekt01 | Yes | 18:49 |
| srichter | right, might not be so hard | 18:49 |
| projekt01 | Perhaps we shold offer more methods for calling (getMenu), perhaps methods where we get in HTML rendered menus | 18:50 |
| J1m | This framework is very mimumal and immature, so there's lots of room to innovate. :) | 18:51 |
| projekt01 | Perhaps a api for calling getRederedMenus where we can register zpt macros for the layout | 18:51 |
| philiKON | projekt01, there's @@view_get_menu | 18:51 |
| J1m | Really, adapters and the basic design pattern make the framework almost non-existent. | 18:51 |
| projekt01 | Jim, Ok | 18:52 |
| projekt01 | Sorry, philiKON, Ok | 18:53 |
| projekt01 | I think the important part is to separate the menu info (dict) and the presentation (layout) | 18:53 |
| philiKON | that's already done | 18:53 |
| projekt01 | Yes, I think we have to offer some rendered menu (trees), that's not supported now | 18:54 |
| projekt01 | Javascript etc | 18:54 |
| projekt01 | Now, without submenues we don't need this | 18:54 |
| projekt01 | Need/have | 18:55 |
| bradb | How does one implement selected menu items. As a request adapter? | 18:57 |
| bradb | I can't think of a better way, but maybe there's something I haven't considered. | 18:58 |
| SteveA | it is a presentation thing | 18:58 |
| SteveA | so, basically, it is up to the view | 18:58 |
| SteveA | it is a view on the menu item that will know that it is "selected" | 18:59 |
| SteveA | also, a view on a collection of menu items may have the constraint that only one is "selected", depending on how you structure these views. | 18:59 |
| bradb | Is there anywhere I can read more about this, or see some example code that does this sort of thing? | 19:00 |
| projekt01 | Ohhh, yes perhaps we have to support only selected menu as marked or all parents too if we support submenues | 19:00 |
| projekt01 | Bradb,the ZMI (rotterdam) marks selected menus. Do you mean how it works? | 19:02 |
| bradb | I'll take a look at the rotterdam skin to see how it does it, thanks. | 19:04 |
| projekt01 | @@get_menu_items view has a method 'selected' simply call view/selected like: | 19:05 |
| projekt01 | <tal:block repeat="view context/@@view_get_menu/zmi_views"> | 19:05 |
| projekt01 | <a href="" | 19:05 |
| projekt01 | tal:attributes="href view/action; | 19:05 |
| projekt01 | class view/selected;" | 19:05 |
| projekt01 | tal:content="view/title" | 19:05 |
| projekt01 | i18n:translate=""> | 19:05 |
| projekt01 | label | 19:05 |
| projekt01 | </a> | 19:05 |
| projekt01 | </tal:block> | 19:05 |
| *** tvon has quit IRC | 19:07 | |
| SteveA | bradb: I expect we'll want to do it in a different way to the rotterdam skin, due to the way we're handling context etc. | 19:08 |
| SteveA | bradb: can we talk about this next week? | 19:09 |
| *** bskahan has joined #zope3-dev | 19:10 | |
| SteveA | bradb: in launchpad, we hold richer information andabout context than you typically get in zope3. I think we should use that information to tell menus whether or not they are selected. But, I may be addled and not thinking clearly. So, decide whether you want to do this now, or wait. We should talk about it anyway. | 19:11 |
| bradb | I'd rather have working code to discuss than not. :) I've only got a few simple options to be selected right now anyway (I think the relative simplicity of the problem will become clearer if you look at the newlook skin.) | 19:12 |
| bradb | Well, "simplicity", once I grok the menu service, which seems easy enough. | 19:12 |
| *** tvon has joined #zope3-dev | 19:23 | |
| regebro | Euuuh... I'm thinking about using a form to display a...well an edit form, but one that belongs to anotehr interface than the object I'm editing. | 19:24 |
| regebro | Is that possible, and how? | 19:24 |
| mgedmin | it is possible | 19:34 |
| mgedmin | one way of doing it is writing a view class | 19:34 |
| mgedmin | that uses setUpWidgets() and getWidgetsData() | 19:34 |
| *** tarek has quit IRC | 19:40 | |
| J1m | It's also possible with the existing form machinery. | 19:40 |
| J1m | You can specify a for that doesn't extend the schema. | 19:40 |
| *** tarek has joined #zope3-dev | 19:40 | |
| J1m | When displaying an edit form, the object being edited is adapted to the form schema. | 19:41 |
| *** SteveA has quit IRC | 19:44 | |
| regebro | J1m, that last part would be wonderful, but it doesn't happen for me. | 19:44 |
| regebro | Maybe it's Five... | 19:44 |
| regebro | Hmmm. | 19:44 |
| regebro | Because what happens in that case is simply that the publisher can't find the edit form. | 19:44 |
| J1m | sounds like a five bug | 19:45 |
| J1m | You have both a for and a schema attr? | 19:45 |
| regebro | Yup. | 19:47 |
| regebro | And, something similar to that happened in the create form, so it's probably a bug in the Five traversal. I'll take a look. | 19:47 |
| *** hazmat has joined #zope3-dev | 19:58 | |
| *** SteveA has joined #zope3-dev | 19:58 | |
| regebro | J1m: Nah, found it. My adapters did stuff that required context of the object adapted, and that seems to not exist at that point. Hum. | 20:06 |
| regebro | Well it's solvable, I think. ;) | 20:06 |
| regebro | Sorry: Required a SPECIFIC context. | 20:07 |
| *** J1m has quit IRC | 20:07 | |
| *** gintas has quit IRC | 20:15 | |
| regebro | Bloody 'ell. 'At works like an british archelogist with a po'ery trowel! I have proxying! I'm so happy. | 20:29 |
| *** MalcolmC has quit IRC | 20:33 | |
| * regebro would kiss J1m if he hadn't already left. | 20:36 | |
| *** stub has left #zope3-dev | 20:42 | |
| *** SteveA has quit IRC | 20:43 | |
| *** ChanServ sets mode: +o hazmat | 20:45 | |
| *** tvon has quit IRC | 20:53 | |
| *** tvon has joined #zope3-dev | 20:53 | |
| *** mgedmin has quit IRC | 21:05 | |
| tarek | I am implementing catalogs to index specific objects (mails) and i was wondering what would be the best practice for my five product : i have based it on a regular zope 2 zcatalog but i am wondering if it will be easily portable to zope 3 later | 21:22 |
| tarek | is there any catalog working yet in zope 3? | 21:28 |
| tvon | its in z3 cvs, haven't tried it myself | 21:28 |
| tvon | er, z3 svn | 21:28 |
| tarek | ok tna | 21:30 |
| tarek | thx | 21:30 |
| *** gintas has joined #zope3-dev | 21:45 | |
| *** bradb has quit IRC | 22:17 | |
| *** alga has quit IRC | 22:21 | |
| *** bradb has joined #zope3-dev | 22:22 | |
| *** alga has joined #zope3-dev | 22:23 | |
| *** bskahan has quit IRC | 22:25 | |
| *** tvon has quit IRC | 22:34 | |
| *** bskahan has joined #zope3-dev | 22:39 | |
| bradb | How do I get the URL of the context object in ZPT? | 22:48 |
| bradb | I've got a little global search box, whose action I want to always be the URL of the context object. | 22:48 |
| srichter | context/@@absolute_url | 22:49 |
| bradb | i'm not looking for the absolute url, just the url to the context object. so, in this case, absolute_url breaks, because this application is placeless. | 22:55 |
| *** niemeyer has quit IRC | 22:55 | |
| *** srichter has quit IRC | 22:55 | |
| *** d2m has quit IRC | 22:55 | |
| *** vinsci has quit IRC | 22:55 | |
| bradb | basically, i want to know if there's an API to get at what the traverser swallowed up to reach my context object | 22:56 |
| *** srichter has joined #zope3-dev | 22:57 | |
| *** d2m has joined #zope3-dev | 22:57 | |
| *** niemeyer has joined #zope3-dev | 22:57 | |
| *** vinsci has joined #zope3-dev | 22:57 | |
| *** irc.freenode.net sets mode: +o srichter | 22:57 | |
| *** srichter has quit IRC | 22:58 | |
| bradb | I think now may be the time for me to starting writing little black boxes that can at least fudge absolute URLs. | 23:00 |
| projekt01 | bradb, what URL are you looking for? The context object only has one URL | 23:00 |
| bradb | projekt01: an IFoo doesn't always have one URL. | 23:01 |
| projekt01 | That's a interface, right? | 23:01 |
| bradb | so, let's say IFoo is my context object. I want the URL the traverser swallowed up to arrive at that IFoo. what that URL is going to be is entirely dependent on how i traversed to the object. | 23:01 |
| bradb | IFoo in our translations app is going to have a different URL than the exact same IFoo in our bugtracking app, hence my not-absolute-url use case. | 23:02 |
| projekt01 | OK, you mean the same object has different URL's | 23:03 |
| bradb | yes | 23:03 |
| projekt01 | Are you sure you whana do that? | 23:03 |
| *** gintas has quit IRC | 23:03 | |
| bradb | projekt01: yes. | 23:03 |
| projekt01 | It's not simple | 23:03 |
| projekt01 | So let's explain | 23:04 |
| bradb | it seems i need an adapter for each "application" to absolute url | 23:04 |
| projekt01 | Wait... | 23:04 |
| projekt01 | Let me ask some questions before | 23:04 |
| projekt01 | You return the same instance in different context | 23:05 |
| projekt01 | Right? | 23:05 |
| projekt01 | Let's say in a list (result) | 23:05 |
| bradb | it's an object that refers to the same db table in a database. it's not necessarily precisely the same instance, but close enough. | 23:05 |
| *** niemeyer has quit IRC | 23:06 | |
| projekt01 | What do you mean not he same instance? | 23:06 |
| bradb | not necessarily the same oid | 23:06 |
| projekt01 | Oid? What's that? | 23:06 |
| bradb | object id. the thing that python uses to refer to an object. | 23:07 |
| bradb | i'm thinking named adapters may be a good idea here | 23:07 |
| projekt01 | Wait, wait... What does python where store, you mean the weakref? | 23:07 |
| projekt01 | We don't have oid's in zope3? It's something that you implement? | 23:08 |
| bradb | projekt01: dude, too low-level here, i'm fairly certain this is irrelevant to solving this problem. :) | 23:08 |
| bradb | i shouldn't have mentioned oid's :) | 23:09 |
| bradb | s/'s/s/ | 23:09 |
| BjornT | bradb: how about "request/URL/-1"? | 23:09 |
| bradb | BjornT: i thought of something like that, but for an IFoo, the URL might be /foo, or /foo/+someview, so it seemed to me that doesn't work. | 23:10 |
| projekt01 | If you like to use the same object under different URL (path) you have to make sure that the traverser can travers the path. | 23:11 |
| projekt01 | You need location proxy for this. | 23:11 |
| bradb | i think writing named adapters for each of my objects to IAbsoluteURL (if that's the right thing to adapt to to solve this problem), using the names of the individual apps as the adapter namespaces is a good start, for now. (placeless apps are pretty hard to work with sometimes.) | 23:11 |
| projekt01 | Each different location (URL) of the same object has to provide the attribute __parent__ where are the revers path to the root. | 23:12 |
| bradb | nah, that's not needed | 23:13 |
| bradb | not if i write my own adapters. | 23:13 |
| bradb | making a placeless app into a placeful one is not a trivial change :) | 23:13 |
| projekt01 | Whould you like to traverse you app? | 23:14 |
| bradb | i know, these adapters are a slight hack (because it means i'm basically hard-coding the path elements leading to the context object for each of the different apps), but i think it's an ok start. | 23:14 |
| bradb | projekt01: our traversals work fine. | 23:14 |
| projekt01 | What are the parents of the object? | 23:15 |
| bradb | projekt01: you're probably making good points, but i have a feeling i'm not very clearly communicating over IRC the context in which things work in this app | 23:15 |
| bradb | projekt01: there are no true __parent__'s in this app | 23:15 |
| projekt01 | Then the object isn't traversable or have you written your own traverser? | 23:16 |
| *** tvon has joined #zope3-dev | 23:18 | |
| bradb | we wrote our own AFAIK (i'd confirm it, but i can't remember what the class name was, and can't be bothered to grep atm :) | 23:19 |
| projekt01 | You don't list this kind of objects in the standard Icontainer view contents.html right? | 23:19 |
| *** regebro has quit IRC | 23:22 | |
| bradb | projekt01: nope, not in the standard one. | 23:22 |
| projekt01 | Why you don't use the default components like traverser, location etc.? | 23:24 |
| bradb | projekt01: I think the reasoning was so that the app could be placeless. | 23:26 |
| bradb | I wasn't there when the decision was made and the solution implemented. | 23:26 |
| *** hazmat has quit IRC | 23:26 | |
| projekt01 | That's no reason for this. Should I explain how to do that? | 23:27 |
| bradb | I know that's the reason for this. :) That's why I'm writing the adapters right now. I'm basically telling Z3 what the locations are going to be, since we have no other way to do so in our system. | 23:28 |
| projekt01 | Yes, that's ok, you have to write location proxy adapter for this. | 23:29 |
| bradb | yep :) | 23:30 |
| projekt01 | But this adapter can yo also write if the object has a location. | 23:30 |
| projekt01 | Let's say a real location | 23:30 |
| projekt01 | And a faked location | 23:30 |
| bradb | sure, i knwo | 23:30 |
| bradb | it's just python code | 23:30 |
| projekt01 | We implemented this already whould you like example code for this? | 23:32 |
| bradb | the only thing that strikes me as problematic is how to use named adapters with foo/@@absolute_url | 23:32 |
| bradb | projekt01: no, it's okay, i think i'm pretty clear on how to do it. my original question was mainly if z3 had an API to make my life easier by providing the URL it consumed to reach the context object, so that my problem is solvable whether the objects are placeful or not. | 23:32 |
| *** srichter has joined #zope3-dev | 23:33 | |
| projekt01 | Yes zope3 has, but you don't have zope3 like objects, you broke the z3 way. | 23:33 |
| bradb | projekt01: what's the z3 way? | 23:34 |
| projekt01 | The API is build on Ilocation and the traverser part | 23:34 |
| bradb | projekt01: what's the function call to get that info? | 23:34 |
| projekt01 | You don't have a URL for this object you have placeless objects? Right? What URL has the parent object? | 23:36 |
| projekt01 | Can you access the parent object from this placeless object | 23:37 |
| projekt01 | If so, write a traversal adapter for traversing your placeless objects | 23:37 |
| projekt01 | Implement Ilocation in the adapter | 23:38 |
| projekt01 | And provide __parent__= your parent object of the placeless object | 23:38 |
| projekt01 | Then you can call object/@@absolute_url | 23:38 |
| projekt01 | And your object act like a placefull object | 23:38 |
| projekt01 | In each place where you like th present the placeless object | 23:39 |
| bradb | I read the "absolute_url" to mean "the one true URL for this object". I'm not looking for "the one true URL for this object", because such a thing doesn't exist in this app. | 23:39 |
| projekt01 | Just adapt the right ILocation | 23:39 |
| projekt01 | No, your URL is built on the fly, there is no absolute URL. Never | 23:40 |
| bradb | Though maybe sub-sites and local adapters would clarify the semantics of "the one true URL", as in "the one true URL /in this app/." | 23:40 |
| projekt01 | There is NO true URL...in Zope3 !!! | 23:41 |
| tvon | Is there any sort of mixin for getting dublin core info or do I need to do "dc = IZopeDublinCore(obj)" ? | 23:41 |
| philiKON | no mixins! | 23:41 |
| projekt01 | A URL is built on the fly if you call a object, if you move a object you don't have to change something. | 23:41 |
| tvon | heh | 23:41 |
| projekt01 | NO nothing.. | 23:41 |
| philiKON | tvon, yes, adapt annotatable objects to IZopeDublinCore | 23:41 |
| philiKON | tvon, z3 is mixin-free! | 23:42 |
| tvon | philiKON: thanks :) | 23:42 |
| philiKON | adapters is the new religion | 23:42 |
| * tvon is still finding his way around | 23:42 | |
| philiKON | there are books out there / about to be released | 23:42 |
| * tvon prepares a glass of kool-aid and starts reading | 23:42 | |
| projekt01 | I don't whana borring you, sorry but please, please, take a look at the Icontainer and Ilocation interfaces. | 23:43 |
| projekt01 | This are really important parts for your solution. | 23:44 |
| *** bskahan has quit IRC | 23:49 | |
| *** ChanServ sets mode: +o srichter | 23:56 | |
| *** niemeyer has joined #zope3-dev | 23:59 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!