fdrake | for the record, everyone consented... | 00:05 |
---|---|---|
*** Alef has quit IRC | 00:16 | |
*** bradb has left #zope3-dev | 00:16 | |
*** mkerrin has quit IRC | 00:22 | |
*** fdrake has quit IRC | 00:23 | |
*** anguenot has joined #zope3-dev | 00:34 | |
*** srichter has joined #zope3-dev | 00:35 | |
*** zbir has joined #zope3-dev | 00:35 | |
*** ChanServ sets mode: +o srichter | 00:35 | |
projekt01 | srichter, this nested menu part in boston skin is a complex usecase for viewlets | 00:42 |
srichter | but do we need to implement them as viewlets? | 00:45 |
srichter | we support nested menus naturally now, so let's not implement them as viewlets for now | 00:45 |
projekt01 | Yes, I think so | 00:46 |
*** sashav has quit IRC | 00:52 | |
*** sashav has joined #zope3-dev | 00:53 | |
projekt01 | srichter, do we really need the update and render methods in viewlet, why do we not use a try/except call in the provider TALES expression | 01:20 |
srichter | because it violates the contract | 01:21 |
srichter | we need to enforce this now, so we can benefit later | 01:21 |
projekt01 | Does Gary base on viewlets? | 01:22 |
srichter | no | 01:22 |
projekt01 | or on content provider? | 01:22 |
srichter | but Gary and viewlets base on content providers | 01:22 |
srichter | you can always create a viewlet base class that provides this method | 01:22 |
srichter | but overall, I want to encourage people to really make use of the two-phase process | 01:23 |
projekt01 | I see all this, but the API is too overloaded for simply things, I think two interfaces where better for define this different things. | 01:26 |
projekt01 | What's about two interfaces instead of two step call | 01:27 |
projekt01 | each interface describes one step, so the TALES expression could check if update should be called or not | 01:28 |
projekt01 | only call update in TALES if a IUpdateAwareProvider is provided | 01:29 |
srichter | no, two phase will be enforced | 01:29 |
srichter | it is the only right way | 01:29 |
srichter | if we allow both, we have to do a lot of documenting explaining when it is not okay to use one phase content providers | 01:29 |
projekt01 | not if you implement def update(self): pass, this smells like a not well defined API to me. | 01:29 |
srichter | and eventually we will say: always use two-phase | 01:30 |
srichter | no, it is well defined | 01:30 |
srichter | the documentation clearly states that it is okay to have an empty update() method | 01:30 |
projekt01 | why not call update only if we provide a interface where defines a update concept? | 01:31 |
srichter | because it is part of the content provider contract that update must be implemented | 01:32 |
projekt01 | We don't need a update concept in every usecase. This is like you implement getter and setter but you define also readonly=True everytime | 01:32 |
srichter | no, but update is much more subtle | 01:32 |
projekt01 | Yes, let's implement two content provider like read and write and the TALES expression can see if the update call is needed | 01:32 |
srichter | and that's the reason I want people to get used to it | 01:32 |
srichter | but the point is not that update is about writing/editing | 01:33 |
srichter | it is about preparing | 01:33 |
srichter | for example, if you set the prefix on a widget, that would be a typical update task | 01:33 |
srichter | when people want to use content providers, I want to force them to learn about the two-phase process and why it is the right way to do things | 01:34 |
srichter | I think the benefit is hard to see right now, but it will be apparent as we use it | 01:35 |
srichter | btw, I think the entire Javascript issue can be solved with this too | 01:35 |
projekt01 | Yes, I totaly agree with you, this is a usecase for use the update concept | 01:36 |
srichter | if you have a view that uses the two phase content providers, then the update() method could tell the view, look I am being rendered and I need this Javascript before the page even starts rendering itself | 01:36 |
projekt01 | I would agree with you at all, if you say that the BrowserView will implement this concept in the future too, I think otherwise we get to far away with viewlets from the view concept. | 01:38 |
projekt01 | I think simply viewlets are only views | 01:38 |
srichter | no, viewlets are not simple views anymore | 01:39 |
srichter | they are content providers | 01:39 |
srichter | and content providers are browser views + some specific semantics | 01:39 |
srichter | (like two-phase rendering) | 01:40 |
srichter | maybe browser views will grow the two-phase method | 01:40 |
srichter | but I am pretty certain that in the next year we are going to switch most page usage to two-phase rendering | 01:41 |
srichter | I think formlib will be taken in this direction | 01:41 |
projekt01 | Ok, then I will implement the push templates if this simply API will expanded. I really like to develop complex views, but what I need is a simply API for simply usecases. | 01:43 |
projekt01 | I think it's Ok to expand all API's, but not if you implement concepts where not needed allways. Then I guess, you should use another level for doing this. | 01:44 |
srichter | right, this level are the content providers | 01:44 |
srichter | we realize that not everyone is always needing the two phases, but they should be always provided | 01:45 |
srichter | like views always have their defaultTraversal() thingy | 01:45 |
projekt01 | I agree in general with you, but I don't like interfaces where I don't have to fully implement. We could get rid of it, if we use two interfaces and make the update part optional. | 01:48 |
projekt01 | Btw, this part is optional and you are describing it in the README.txt | 01:48 |
projekt01 | Why do we not offer a second interface for optional API's? | 01:49 |
srichter | wher edo I say it is optional? | 01:49 |
srichter | where do I say it is optional? | 01:49 |
projekt01 | def update:pass is optional for me ;-) | 01:49 |
srichter | no, it is not!!!!!! | 01:50 |
srichter | it is merely empty! | 01:50 |
projekt01 | Ok, without this method the implementation breaks only because of the call in TALES | 01:51 |
*** J1m has quit IRC | 01:51 | |
srichter | no, not only there | 01:52 |
srichter | what if another piece of saoftware wants to use this code? | 01:52 |
srichter | they expect the update to be there? | 01:52 |
srichter | they expect the update to be there! | 01:52 |
projekt01 | Not if we implement a interface where update defines | 01:52 |
srichter | from their perspsective it would be dubious to have to write a try/expect or interface check | 01:53 |
srichter | but then those softwares have to wrory about two interfaces, instead of one | 01:53 |
srichter | and they have to handle those cases in special ways | 01:54 |
srichter | even worse, if some other content providers expect two-phases to be there | 01:55 |
srichter | so for one case, you have 4-6 lines instead of two and that will multiply for everything that wants to use the two-phase system | 01:55 |
srichter | and you have to admit, the price we pay is very small | 01:56 |
projekt01 | and now we have to use def update:pass averytime, which I think it's also not nice. | 01:56 |
srichter | if you use a base class, you have no additional overhead, and if you dont use one you have to write: | 01:56 |
srichter | def update(self): pass | 01:56 |
projekt01 | yes | 01:57 |
srichter | as I said, this is a small price to pay | 01:57 |
projekt01 | Ok, I give up ;-) | 01:57 |
srichter | good | 01:57 |
srichter | :-) | 01:57 |
srichter | btw, I totally see where you are coming from | 01:58 |
srichter | I was thinking about this for a long time too | 01:58 |
srichter | but it is for the good of all that we do this :-) | 01:58 |
srichter | its like using adapters versus inheritance | 01:58 |
srichter | forcing everyone to use adapters is much more work at the beginning, but the long-time benefits are greater :-) | 01:59 |
projekt01 | You are right, my target was only to get a simply API for new users, but perhaps it's better for the future to bring people to the use of this two step call | 01:59 |
projekt01 | But we have to be careful, this makes the learning curve much higher. | 02:00 |
srichter | yes, I agree | 02:01 |
srichter | but it will save them ugly headaches later | 02:01 |
projekt01 | And I think for new developer, it's allways a pain to understand the concept if the interfaces handle to much uscease | 02:01 |
srichter | for them we will have high-level directives that hide this flexibility | 02:02 |
srichter | ZCML often does that actually (whether this is good or bad) | 02:02 |
*** deo has quit IRC | 02:02 | |
projekt01 | Ok, your second point today, now we have a 2:0 for you ;-) | 02:03 |
*** deo has joined #zope3-dev | 02:03 | |
projekt01 | Ok, I will go back to the boston skin and implement this part ;-) | 02:03 |
srichter | that first argument was not easy, because I see where you are coming from and I partially agree; I just try to look ahead | 02:04 |
srichter | once we fully embrace viewlet/portlet based page creation, we will always use the two phase process | 02:04 |
srichter | I am really looking forward to developing a new page concept for the upcoming Zope 3 release | 02:05 |
srichter | s | 02:05 |
srichter | I have already some ideas | 02:05 |
projekt01 | Yes, I agree, that's excatly what we need for portlets | 02:06 |
projekt01 | Are you thinking about push templates? | 02:06 |
projekt01 | I implemented a prototype, it's amazing what you can do with a push template concept! | 02:07 |
srichter | yeah, I think it will be push templates | 02:08 |
projekt01 | It allows you totaly new kind of implementations. Because the brain get not overloaded with all this macro and TAL parts | 02:08 |
srichter | right | 02:08 |
srichter | it is all Python and content providers :-) | 02:09 |
projekt01 | cool, take a look at KID templates | 02:09 |
srichter | I wish I had time | 02:11 |
projekt01 | We can write a mail to the list after the release, I guess other people will love and join this development | 02:12 |
projekt01 | ;-) | 02:13 |
srichter | I agree | 02:13 |
projekt01 | Ok, hope I can commit a working boston skin branch tonight. | 02:14 |
srichter | that would awesome | 02:14 |
projekt01 | I let you know if I'm ready. btw, I'm out of office tomorrow and back at night. | 02:14 |
srichter | ok | 02:14 |
projekt01 | When do you need a working version for the release | 02:14 |
projekt01 | I hope to get finished at saturday | 02:15 |
srichter | I am looking forward to it | 02:16 |
projekt01 | Ok | 02:16 |
*** tiredbones has quit IRC | 02:42 | |
*** SteveA has quit IRC | 02:44 | |
*** tiredbones has joined #zope3-dev | 02:44 | |
*** xenru|clone has joined #zope3-dev | 03:02 | |
*** tiredbones has quit IRC | 03:04 | |
*** zbir has quit IRC | 03:04 | |
*** xenru has quit IRC | 03:04 | |
*** gnosis has quit IRC | 03:04 | |
*** vinsci has quit IRC | 03:04 | |
*** zbir has joined #zope3-dev | 03:07 | |
*** tiredbones has joined #zope3-dev | 03:20 | |
*** stub has joined #zope3-dev | 03:40 | |
projekt01 | srichter, ayt? | 03:51 |
projekt01 | srichter, is it correct that there is no way to register submenus for the "Add" menu because of how the "Add" menu get registered in the view directive | 03:55 |
projekt01 | Argh, I guess we have to expand the view and page and all other directive and support a submenu registration there. | 03:55 |
projekt01 | This will allow us to register submenus to this new regsitered menu (submenu-parent) | 03:57 |
projekt01 | Right now the menu attribute in the view directive will only register a menu item" but there is no way to register a "menu" in a view directie where we need for submenus | 03:58 |
projekt01 | This means if we use a menu attribute in a view or page directive we also have to register a menu and not only a menu-item for providing submenue on this menu-item | 04:03 |
projekt01 | srichter, forget about the Boston skin for this release, we have to re-implement menus first. We need nested menus and not menu and menu-item. | 04:07 |
projekt01 | Nested menus means we don't have menu-items anymore. Menu-items will become menus, otherwise we can't build a nested structure. | 04:09 |
projekt01 | Your demo of nested menues works only if you have full control over the registration, but this won't work for register sub-menu for allready defined menus (via view or page directive) | 04:10 |
*** whit has joined #zope3-dev | 04:11 | |
projekt01 | srichter, drop me a note what you think about this if you read the IRC log | 04:12 |
*** projekt01 has quit IRC | 04:12 | |
*** whit has quit IRC | 04:25 | |
*** stub has quit IRC | 04:38 | |
*** stub has joined #zope3-dev | 04:39 | |
*** sashav has joined #zope3-dev | 04:45 | |
*** niemeyer has quit IRC | 04:53 | |
*** xenru has joined #zope3-dev | 05:51 | |
*** xenru|clone has quit IRC | 06:08 | |
*** natea has joined #zope3-dev | 06:12 | |
*** deo has quit IRC | 06:21 | |
*** natea has quit IRC | 07:53 | |
*** natea has joined #zope3-dev | 08:03 | |
*** sashav has joined #zope3-dev | 08:34 | |
*** dobee has joined #zope3-dev | 08:51 | |
*** sashav has quit IRC | 08:51 | |
*** dlk has joined #zope3-dev | 08:57 | |
*** zagy has joined #zope3-dev | 09:19 | |
*** povbot has joined #zope3-dev | 09:51 | |
*** Soulraven has joined #zope3-dev | 10:00 | |
*** xenru has quit IRC | 10:24 | |
*** sashav has joined #zope3-dev | 10:25 | |
*** MJ has quit IRC | 10:30 | |
*** vlado has joined #zope3-dev | 11:16 | |
*** MJ has joined #zope3-dev | 11:22 | |
*** tarek has joined #zope3-dev | 11:59 | |
Theuni | when is the feature freeze for zope 3.3? | 12:04 |
Theuni | is that in march? | 12:04 |
Theuni | ah. it's may | 12:12 |
*** anguenot has quit IRC | 12:16 | |
*** efge has joined #zope3-dev | 12:16 | |
*** projekt01 has joined #zope3-dev | 12:24 | |
projekt01 | srichter, ayt? | 12:25 |
*** faassen has joined #zope3-dev | 13:06 | |
*** mp has joined #zope3-dev | 13:11 | |
*** mgedmin has joined #zope3-dev | 13:13 | |
*** tarek_ has joined #zope3-dev | 13:42 | |
*** tarek has quit IRC | 13:43 | |
*** mkerrin has joined #zope3-dev | 13:47 | |
srichter | projekt01: JM just checked in some two-phase rendering code too | 13:53 |
*** xenru has joined #zope3-dev | 13:56 | |
*** philiKON has joined #zope3-dev | 13:59 | |
*** philiKON is now known as phlKN | 14:11 | |
*** phlKN is now known as philiKON | 14:12 | |
*** tarek has joined #zope3-dev | 14:13 | |
*** stub has quit IRC | 14:15 | |
*** tarek_ has quit IRC | 14:28 | |
*** JoaoJoao has joined #zope3-dev | 14:36 | |
JoaoJoao | hello | 14:36 |
JoaoJoao | I'm trying to find out how to group all users from a principal source and give them a special role, but I don't know how =( | 14:44 |
srichter | use a group | 14:46 |
JoaoJoao | I don't know the ZCML to create a group :P | 14:46 |
srichter | oh, this work only for TTW created users | 14:47 |
srichter | ZCML should only define the most basic users | 14:47 |
JoaoJoao | srichter: I want to give all users from my principal source a special role, is there a way to do that? | 14:48 |
srichter | no not this directly | 14:50 |
srichter | you have to use a group | 14:50 |
srichter | or some subscriber that listens for IPrincpalCreated event | 14:50 |
JoaoJoao | srichter: The problem is, the principal source is to authenticate users from a Firebird DB, and the users are alrady there | 14:54 |
JoaoJoao | s/alrady/already | 14:54 |
*** zbir has quit IRC | 14:54 | |
srichter | right | 14:54 |
srichter | IPrincipalCreated is called every time a user is looked up | 14:55 |
srichter | you should really read the zope.app.authentication/README.txt | 14:55 |
srichter | if you don't get it, read it again until you do | 14:55 |
srichter | this might seem harsh, but we cannot take the laerning process from you | 14:56 |
srichter | (note that I have read the zope.wfmc txt files about 4-5 times before I knew what was going on) | 14:56 |
JoaoJoao | I'll read it right now, thanks | 14:57 |
JoaoJoao | btw, this Zope3 API Docs thing is great | 14:57 |
srichter | thanks | 14:57 |
srichter | btw, I am always looking for suggestions of improvement | 14:58 |
projekt01 | srichter, I saw JM's commit | 14:58 |
projekt01 | srichter, did you see my notes in the IRC about menu and menu items? | 14:58 |
srichter | yeah, but I have not studied them carefully yet | 14:59 |
projekt01 | the problem is we can't register sub-menu for the Add menu itself ,because "Add" is only registred menu item but there is no menu weher we can use for registering submenus | 15:00 |
projekt01 | We can take a look at this later | 15:00 |
projekt01 | I guess we have to change the menu implementation for this | 15:00 |
srichter | do you have a proposed solution? | 15:04 |
projekt01 | not yet, I just recognized the issue, I think we should get rid of menu items and only use menus | 15:05 |
projekt01 | a menu item whould be a (sub)menu on another menu | 15:06 |
srichter | I see | 15:06 |
projekt01 | But we have to think about the dependency | 15:06 |
srichter | I definitely have to think sbout this carefully | 15:06 |
projekt01 | Yes | 15:06 |
srichter | but what you are saying sounds right | 15:06 |
projekt01 | The problem is, if we register a view and use the menu attribute, we only get a menu item, but what we need is a submenu aware menu | 15:07 |
srichter | hdima: ah, now I see how you tell about the password manager in ZCML | 15:07 |
srichter | hdima: I was thinking about using something like "<CRYPT>pasword-string" | 15:08 |
srichter | projekt01: so is that not a limitation of the view-directives? | 15:09 |
projekt01 | no we don't create a menu if we use the attribute menu in page or view directive. | 15:10 |
projekt01 | we only register a menu item | 15:10 |
srichter | right | 15:10 |
projekt01 | on menu items we can't register submenus | 15:10 |
projekt01 | only on menus | 15:10 |
srichter | Oh, I see what you are saying | 15:11 |
projekt01 | I guess we can get rid of menu items and use allways menues where are submenu aware | 15:11 |
srichter | I really think we should stop using the menu specification pattern int he view directives | 15:11 |
projekt01 | Yes, why not | 15:11 |
projekt01 | The definition (ZCML) would be much clearer | 15:12 |
srichter | right | 15:12 |
projekt01 | Ok, let's think about that after the release | 15:13 |
srichter | so let's do that for now: If you want to use sub-menus don't use the menu and titel attribute in the view directives | 15:13 |
projekt01 | Yes, ... and register the menu and it's submenu in a own directive | 15:14 |
*** stub has joined #zope3-dev | 15:14 | |
srichter | right | 15:15 |
projekt01 | That works, it only will not work with the containerView etc directive where use implicit menu item registration | 15:15 |
srichter | ok | 15:16 |
projekt01 | Ok, I'll move the nested menu part out of the Boston skin tonight, so we can use it as a clean viewlet sample | 15:16 |
projekt01 | with normal menus | 15:17 |
srichter | great! | 15:17 |
projekt01 | Hope to get ready tomorrow ;-) | 15:17 |
projekt01 | dobee, ayt? | 15:18 |
hdima | srichter: It's hard to achieve backward compatibility this way: '<CRYPT>password' | 15:18 |
srichter | true | 15:19 |
dobee | projekt01: jep | 15:19 |
srichter | so "password" could be interpreted as: use the default password manager, which is "Plain Text" | 15:19 |
projekt01 | dobee, can you give me your email address, so I will send you the announcement form Dominik for the sprint | 15:19 |
srichter | hdima: so "password" could be interpreted as: use the default password manager, which is "Plain Text" | 15:19 |
dobee | bernd.dorn --at--- fhv.at | 15:20 |
srichter | hdima: oh, never mind, I guess if you do not specify a password manager, "Plain Text" is used | 15:20 |
hdima | yes, "Plain Text" is default | 15:21 |
srichter | ok | 15:21 |
dobee | projekt01: seen it? | 15:21 |
projekt01 | Yup, did you get the mail? | 15:22 |
*** sashav has quit IRC | 15:22 | |
hdima | srichter: did you try bin/zpasswd? | 15:22 |
*** sashav has joined #zope3-dev | 15:22 | |
dobee | projekt01: yes, 'hope i can come | 15:25 |
projekt01 | would be nice to see you again | 15:26 |
projekt01 | srichter, did you see the mail form JM right now? | 15:27 |
*** Faelin has left #zope3-dev | 15:31 | |
*** tarek has quit IRC | 15:36 | |
*** tarek has joined #zope3-dev | 15:37 | |
*** MrTopf has joined #zope3-dev | 15:39 | |
*** ignas has joined #zope3-dev | 15:43 | |
*** jvts has joined #zope3-dev | 15:52 | |
*** projekt01 has quit IRC | 15:53 | |
philiKON | srichter, ayt | 16:02 |
philiKON | ? | 16:02 |
*** zbir has joined #zope3-dev | 16:03 | |
*** SteveA has joined #zope3-dev | 16:04 | |
*** mgedmin has quit IRC | 16:08 | |
*** benji has joined #zope3-dev | 16:13 | |
*** J1m has joined #zope3-dev | 16:14 | |
*** sashav has quit IRC | 16:15 | |
*** tarek_ has joined #zope3-dev | 16:20 | |
srichter | philiKON: yeah | 16:26 |
srichter | benji: I might have found a way to make testbrowser work with error pages | 16:27 |
faassen | hm, what's the status in Zope 3.1 concerning timezones.. | 16:27 |
srichter | luckily the HTMLError contains the full response | 16:27 |
faassen | I tried to figure out things through the mailing list but I'm not sure where all the different pieces fit. | 16:27 |
srichter | faassen: I cannot remember at all | 16:27 |
faassen | srichter: that's not good. :) | 16:28 |
srichter | benji: but HTMLError can also have a URL not found error, in which case there is no response body, so it needs some thinking | 16:28 |
srichter | faassen: I remember trying to support timezone parsing in zope.i18n and it worked | 16:28 |
faassen | there's an Olson database, there's information in the request, locale, there's input of datetimes, storage in the ZODB, output in the current locale's timezone. | 16:28 |
srichter | faassen: also timezones have been fixed to be peristable | 16:29 |
faassen | I don't care about timezone parsing particularly. I care about storing data as UTC. | 16:29 |
faassen | dates as UTC. | 16:29 |
faassen | but outputting them in a particular timezone. | 16:29 |
faassen | if I need to configure this timezone in the app, that's okay for now. | 16:29 |
faassen | if it can somehow be deduced from the request, that'd be good too. | 16:29 |
srichter | I think there is currently a disconnect from the locale to the timesone | 16:29 |
faassen | hm. | 16:29 |
srichter | because the timezone info in the ICU files sucks | 16:29 |
srichter | in fact they even discourage using it | 16:30 |
faassen | yes, I think there was discussion about this stuff in Zope 3.2? | 16:30 |
faassen | use Olson database instead or whatnot. | 16:30 |
srichter | right | 16:30 |
faassen | does the request contain enough detail in theory to deduce the timezone of the user at all? | 16:30 |
srichter | use pytz instead | 16:30 |
srichter | so I think that means setting it by hand for now :-( | 16:30 |
faassen | well, the pytz included with 3.1 doesn't contain the Olson database, right? | 16:30 |
srichter | the code is autogenerated from the Olsen data | 16:31 |
srichter | you want to talk to stub for detai;s | 16:31 |
*** zagy has quit IRC | 16:31 | |
srichter | you want to talk to stub for details | 16:31 |
*** tarek has quit IRC | 16:31 | |
faassen | hm. | 16:32 |
stub | pytz is a port of the Olson data into python land | 16:32 |
faassen | stub: does Zope 3.1 ship with that version? | 16:32 |
faassen | stub: or at least a useful enough version? :) | 16:32 |
stub | The version in 3.1 is pretty recent | 16:32 |
faassen | stub: hey, you're around, my luck. | 16:32 |
faassen | stub: okay.. hm, well, so I still don't know where to start. I have input fields, which need to know the timezone the user is in. | 16:33 |
faassen | stub: can this be reliably extracted from the request? | 16:33 |
stub | Nope | 16:33 |
faassen | stub: so the application just has to know its timezone(s), right? | 16:33 |
faassen | stub: either with per-user config, or global config. | 16:33 |
stub | It is possible to do it unreliably, but I don't think it is worth the effort | 16:33 |
faassen | stub: understood. | 16:33 |
stub | Yes - you need to store the timezone | 16:33 |
faassen | stub: so how does Zope 3 make sure *its* timezones are stored at UTC in the ZODB, do you know? | 16:34 |
faassen | stub: as I don't recall it actually asking for my timezone.. use server's timezone? | 16:34 |
stub | Probably. I'm not sure. | 16:34 |
srichter | storing dates in UTC is a convention, not an enforced rule | 16:35 |
faassen | stub: the datetime module + pytz contains enough API and info to convert an entry in some timezone.. | 16:35 |
srichter | so it is up to the application | 16:35 |
faassen | srichter: yes, I'd like my application to do it, as I need UTC datetimes for other reasons in it anyway.] | 16:35 |
faassen | stub: is that correct? | 16:35 |
* Theuni hmms a bit | 16:35 | |
stub | yes. | 16:35 |
faassen | stub: to UTC, I was going to finish typing.. :) anyway, hm.. | 16:36 |
Theuni | J1m: you there, got some time? | 16:36 |
Theuni | srichter: you wanted to know something about the certification? | 16:36 |
faassen | so, I need to make sure my datetime display and input widgets know what timezone to display in/get input in. | 16:36 |
faassen | and then convert to and from UTC. I guess I can make some special widgets that do that for now. | 16:36 |
philiKON | srichter, sorry, was gone | 16:37 |
philiKON | never mind actually, i think i figured it out | 16:39 |
srichter | Theuni: no, I just wanted to know the status? :-) | 16:39 |
srichter | faassen: right | 16:40 |
*** tarek has joined #zope3-dev | 16:40 | |
Theuni | srichter: we're reactivating it again ... i have a really good plan to get it finally done | 16:40 |
Theuni | i'm aiming to get zope 3.3 certified | 16:40 |
srichter | cool | 16:40 |
Theuni | i'm trying to get sort some stuff out and then my current plan is to start working on November 14 and spent 5 whole weeks of my time doing documentation and some implementation | 16:41 |
Theuni | s/get sort/sort/ | 16:41 |
srichter | philiKON: there is a nasty bug in static tree that if you manually expend all nodes, the states are not correctly updated. | 16:44 |
philiKON | ups | 16:44 |
srichter | philiKON: yeah, it basically sets the expand flag to true, but does not update some other state variable | 16:45 |
srichter | I think you can fix this in less than an hour; I just did not have enough static tree zen | 16:45 |
philiKON | i'm really swamped with five work | 16:45 |
philiKON | it sounds to me like you figured out most of it already | 16:46 |
srichter | the bug is around for a long time, so it can be fixed in the bug fixing time :-) | 16:46 |
philiKON | +1 | 16:47 |
srichter | (btw, the static version of the apidoc demonstrates this bug in the menus | 16:48 |
*** xenru has quit IRC | 16:51 | |
*** tarek_ has quit IRC | 16:53 | |
*** christi has joined #zope3-dev | 16:55 | |
*** vinsci has joined #zope3-dev | 16:59 | |
*** christi has left #zope3-dev | 17:01 | |
*** natea is now known as natea|away | 17:03 | |
*** bradb has joined #zope3-dev | 17:05 | |
*** jvts has left #zope3-dev | 17:14 | |
*** hdima has quit IRC | 17:21 | |
*** dlk has quit IRC | 17:22 | |
*** natea|away is now known as natea | 17:22 | |
*** mgedmin has joined #zope3-dev | 17:28 | |
*** dobee has quit IRC | 17:29 | |
*** baldtrol has joined #zope3-dev | 17:30 | |
baldtrol | morning everyone. or, morning for me, anyway :) | 17:32 |
VladDrac | good afternoon | 17:34 |
baldtrol | question (because i *always* have questions)... how, through the zmi, can i register an unnamed Unique Id utility? all of my catalog attempts keep failing because, by default, when i add an IntIds utility, it names it IntIds... | 17:36 |
baldtrol | and the catalog getUtility methods just try for zapi.getUtility(IIntIds) ...at the debugger i can get it, by giving it context or a name, but outside of overriding all the catalog methods and explicitly passing in context, i don't know what else to do. | 17:38 |
*** anguenot has joined #zope3-dev | 17:40 | |
philiKON | baldtrol, just don't provide a name of the utility | 17:49 |
philiKON | when you register it | 17:50 |
*** tarek has quit IRC | 17:50 | |
baldtrol | i tried that... it still adds one. but i can try it again, i could be a little brane-dead, it being friday and all. | 17:51 |
*** tarek has joined #zope3-dev | 17:51 | |
baldtrol | hmm. nevermind. registration manager shows the below, but it still fails. must be something else. thanks. | 17:54 |
baldtrol | * provided: zope.app.intid.interfaces.IIntIds | 17:54 |
baldtrol | * name: <no name> | 17:54 |
baldtrol | * component: IntIds | 17:54 |
*** tarek has quit IRC | 18:12 | |
*** tarek has joined #zope3-dev | 18:12 | |
tiredbones | I'm trying to run benjiyork's Quick Start Guide. I bomb out every time I add the slug in.So I start runzope with pdb to find where I'm getting a directory that dose not exist anymore.As I step thru runzope everthing looks ok. When I get to the "from"statement is when I get mu bogis directory.Isn't the "from" statement using the sys.path built in the previous setp being used? | 18:17 |
tiredbones | I'm trying to run benjiyork's Quick Start Guide. I bomb out every time I add the slug in.So I start runzope with pdb to find where I'm getting a directory that dose not exist anymore.As I step thru runzope everthing looks ok. When I get to the "from"statement is when I get mu bogis directory.Isn't the "from" statement using the sys.path built in the previous setp being used in the "from" statement? | 18:18 |
benji | tiredbones, what is the exact error you're seeing (last 15-20 lines would be good); use http://pastebin.com/ (or similar, don't paste it here) | 18:19 |
tiredbones | benji, I have to take my son to school, will do this when I come back. thanks | 18:20 |
benji | tiredbones, sure | 18:20 |
srichter | benji: did you see my message earlier about the HTTP error thing? | 18:22 |
benji | nope | 18:22 |
srichter | ah ok | 18:22 |
benji | ok, I just read it | 18:23 |
srichter | so I figured out that the response file object is tagged onto the HTTPError | 18:23 |
srichter | so we would actually have access to the info we need, if we try/except the error | 18:23 |
srichter | the question is now, wher eto out the fix | 18:23 |
srichter | I think the best place would be mechanize browser | 18:24 |
srichter | and add an option to the Browser class, whether the error should be caught or not | 18:24 |
srichter | benji: thoughts? | 18:27 |
*** MJ has quit IRC | 18:29 | |
benji | srichter, I'm not quite sure what you're saying there | 18:32 |
benji | is the exception captured in the response? | 18:32 |
srichter | ok, so let's say a URL throws 404 | 18:33 |
srichter | urllib2 will raise an HTTPError | 18:34 |
srichter | however, we want to be able to get the contents of the error page | 18:34 |
benji | right | 18:34 |
srichter | I am saying that the HTTPError has the contents | 18:34 |
srichter | error.info | 18:34 |
JoaoJoao | I'm trying to assign a role do a user in IPrincipalCreated | 18:37 |
JoaoJoao | (s/do a/to a) and I have a ConflictError, not sure what it means | 18:38 |
benji | srichter, HTTPError has the html from the error page? | 18:38 |
benji | i'm confused | 18:38 |
srichter | yes | 18:39 |
srichter | so if we catch the error somewhere we can get all the data we want | 18:39 |
benji | and the html has the traceback in it? | 18:40 |
srichter | what traceback? | 18:41 |
benji | who's on first? | 18:41 |
srichter | huh? | 18:41 |
benji | ok, I'm *really* not understanding what's going on | 18:41 |
bob2 | traceback's on second? | 18:41 |
benji | what's pitching | 18:41 |
srichter | ok, let's rewind | 18:42 |
benji | srichter, sorry, 50 year old American cultural reference :) | 18:42 |
srichter | we have developed a page that will be displayed when the URL was not found | 18:42 |
srichter | this page gives the user a nice message saying that the URL does not exist | 18:42 |
srichter | it sets the return status to 404 | 18:43 |
benji | ok | 18:43 |
srichter | or "404 Not Found" to be precise | 18:43 |
benji | rith | 18:43 |
benji | right | 18:43 |
* benji ignores what Jim is about to say | 18:43 | |
srichter | now, we want to test this page using testbrowser | 18:43 |
benji | ok | 18:44 |
srichter | browser = Browser() | 18:44 |
srichter | browser.open('http://localhost/unknown') | 18:44 |
J1m | srichter, have you never hear: | 18:44 |
J1m | http://www.baseball-almanac.com/humor4.shtml | 18:44 |
J1m | ? | 18:44 |
srichter | J1m: no | 18:44 |
J1m | eek | 18:44 |
srichter | but the open call will not return | 18:44 |
srichter | (I HATE BASEBALL!) | 18:45 |
J1m | It's one of the funniest skits of all time. | 18:45 |
srichter | I'll read through it | 18:45 |
srichter | the open() call will raise an error | 18:45 |
srichter | urllib2.HTTPError specifically | 18:45 |
baldtrol | J1m: yes it is :D | 18:45 |
srichter | this really sucks for us, because it is not the behavior a browser would have | 18:46 |
srichter | so, I believe the call should just work | 18:46 |
*** andres has joined #zope3-dev | 18:47 | |
*** suse-joe has joined #zope3-dev | 18:47 | |
srichter | the question is now where to catch the HTTPError and handle everything correctly | 18:48 |
*** tarek_ has joined #zope3-dev | 18:50 | |
srichter | J1m: btw, I think we should move the release schedule to a January/July rotation | 18:50 |
srichter | J1m: Europe is just dead during the last week of December | 18:50 |
*** tarek_ has joined #zope3-dev | 18:50 | |
J1m | srichter, we shouldn't be making the release the last week of december. | 18:52 |
J1m | We should be making the release before the holidays so we can enjoy them. | 18:52 |
srichter | I think it needs to be at the latest December 20th | 18:52 |
J1m | sounds good to me. | 18:52 |
J1m | We should aim for Dec 1. | 18:53 |
J1m | and let it slip no later than Dec 1. | 18:53 |
srichter | what? :-) | 18:54 |
srichter | benji: are you still there? | 18:54 |
benji | yep | 18:54 |
J1m | and let it slip no later than Dec 20. | 18:55 |
srichter | ok | 18:56 |
benji | srichter, so you're saying that when you get a 404, mechanize will always raise an exception instead of letting you choose to see the page contents instead | 18:56 |
benji | ? | 18:56 |
srichter | yes | 18:56 |
benji | I'd propose a change on the mechanize list (or we can catch the exception and set browser.contents ourselves) | 18:56 |
JoaoJoao | I did the assignRoleToPrincipal on the IPrincipalCreated event and I have a ConflictError: http://pastebin.com/409032 | 18:56 |
srichter | benji: by ourselves you mean in testbrowser? | 18:57 |
srichter | that would be possible, but not desirable | 18:57 |
srichter | because you also want to access links, etc | 18:57 |
* srichter really wishes mechanize would have unit tests | 18:58 | |
*** tarek has quit IRC | 19:00 | |
benji | srichter, right, I think the best choice would be to add a flag to mechanize to not raise exceptions on non-200 status codes | 19:04 |
srichter | yep | 19:05 |
srichter | I guess I can add this to our code base and we can send a diff | 19:05 |
srichter | I have several other changes I am about to check in | 19:05 |
*** strichter has joined #zope3-dev | 19:14 | |
*** srichter has quit IRC | 19:15 | |
*** strichter is now known as srichter | 19:16 | |
*** ChanServ sets mode: +o srichter | 19:16 | |
suse-joe | Hi! Is there an easy way of defining container constraints like "should contain at least one, but no more than five subobjects"? | 19:23 |
srichter | no, not by default | 19:32 |
*** MrTopf has quit IRC | 19:32 | |
srichter | but you can write your own costraints | 19:32 |
srichter | similar to the container constraints | 19:32 |
*** philiKON has quit IRC | 19:32 | |
*** xenru has joined #zope3-dev | 19:33 | |
*** natea is now known as natea|away | 19:39 | |
suse-joe | srichter: Ok. That's what I was about to try. | 19:39 |
*** jinty has joined #zope3-dev | 19:47 | |
tiredbones | benji, ayt/ | 19:51 |
*** suse-joe has left #zope3-dev | 20:04 | |
*** efge has quit IRC | 20:06 | |
*** alga has joined #zope3-dev | 20:08 | |
*** dobee has joined #zope3-dev | 20:13 | |
*** jinty has quit IRC | 20:13 | |
*** dobee has quit IRC | 20:14 | |
*** vlado has quit IRC | 20:23 | |
*** regebro has joined #zope3-dev | 20:23 | |
*** MJ has joined #zope3-dev | 20:26 | |
*** alga has quit IRC | 20:30 | |
*** dobee has joined #zope3-dev | 20:31 | |
JoaoJoao | anyone here with experience on IPrincipalRoleManager, IPrincipalCreated and that stuff? | 20:34 |
*** SteveA has quit IRC | 20:35 | |
*** faassen has quit IRC | 20:35 | |
*** deo has joined #zope3-dev | 20:39 | |
*** andres has quit IRC | 20:46 | |
benji | tiredbones, IAH :) | 20:59 |
JoaoJoao | ConflictError on assignRoleToPrincipal | 21:00 |
*** mkerrin has quit IRC | 21:07 | |
*** SteveA has joined #zope3-dev | 21:22 | |
*** stub has quit IRC | 21:30 | |
*** regebro has quit IRC | 21:32 | |
tiredbones | benji, I'm going to send the trceback now. | 21:33 |
benji | ok | 21:33 |
*** anguenot has quit IRC | 21:34 | |
tiredbones | benji, did it come across ok? | 21:35 |
benji | where? | 21:36 |
tiredbones | benji, http://pastebin.com | 21:37 |
benji | what's the rest of the URL? There should be some numbers on the end. | 21:37 |
benji | ah, I found it | 21:38 |
benji | tiredbones, it's http://pastebin.com/409185 right? | 21:38 |
tiredbones | benji, yes | 21:38 |
benji | ok, tiredbones, the first problem is that you're using the quick start with 3.1, it requires a checkout of what will become 3.2 (the instructions at the begining of the quick start tell you how to check it out) | 21:39 |
*** q[monty] has joined #zope3-dev | 21:41 | |
JoaoJoao | how do I use an IPrincipalCreated event subscriber to assign roles to principals? I tried this, with no success: http://pastebin.com/409190 | 21:41 |
*** tarek_ has quit IRC | 21:42 | |
benji | srichter, AYT? | 21:43 |
*** tarek_ has joined #zope3-dev | 21:43 | |
tiredbones | benji, What told you, in the traceback, that I have the wrong version of Zope? | 21:43 |
q[monty] | I've got a page defined "for" an interface. When I access that page in the context of an object that implements that interface, why can I not access methods of the instance object from the context variable in ZPT? | 21:43 |
benji | tiredbones, because you said "the path /home/wayne/Desktop/Zope-3.1.0c1 no longer exist" | 21:44 |
q[monty] | I got it to work by giving the page a 'class' and accessing it through the view var... but that seems wrong to me in this case. | 21:44 |
benji | q[monty], by "not access" do you mean you get some sort of exception, "Forbidden" perhaps? | 21:44 |
mgedmin | q[monty], do you have adequate security declarations? | 21:44 |
q[monty] | let me see what the error was... | 21:45 |
q[monty] | I got a TraversalError | 21:45 |
tiredbones | benji, Thanks, I'll try updating to 3.2. | 21:46 |
benji | NP, tiredbones | 21:46 |
JoaoJoao | benji: What's new on the soon-to-be 3.2? | 21:47 |
mgedmin | q[monty], ForbiddenAttributeError is a subclass of AttributeError | 21:48 |
mgedmin | I think the default TALES path traverser converts all AttributeErrors to TraversalErrors | 21:49 |
mgedmin | so if you do not have security declarations for your content objects, you are likely to get TraversalErrors | 21:49 |
benji | JoaoJoao, lots, I can't remember it all | 21:49 |
JoaoJoao | I'll stick to 3.1 for now, I'm fighting with PAU, it's beating me up | 21:50 |
q[monty] | mgedmin, Aha! That's not very intutive... thanks! We do security declarations in zcml now, right? | 21:50 |
mgedmin | yes | 21:51 |
mgedmin | <content class="..."> <require permission="zope.ManageContent" interface="..." /> ... </content> | 21:52 |
mgedmin | (off the top of my head) | 21:52 |
mgedmin | <allow ... /> is a synonim for <require permission="zope.Public" ... /> | 21:52 |
mgedmin | <require> takes one or more of interface="..." attributes="foo bar baz ..." set_attributes="foo bar baz ..." set_schema="..." | 21:52 |
mgedmin | hth | 21:52 |
q[monty] | mgedmin, yes... very much. Thank you. | 21:53 |
q[monty] | mgedmin, SWEET! It works as expected now. | 21:56 |
*** Aiste has joined #zope3-dev | 21:59 | |
tiredbones | benji, I'm doing the svn thing, but I still have Q.. Why did those path that I deleted show up? | 22:02 |
tiredbones | benji, I'm doing the svn thing, but I still have Q.. Why did those path that I deleted show up in the starting of runzope? | 22:03 |
benji | tiredbones, I didn't look deeply enough to know; did you make an instance in one place and then move it? | 22:03 |
tiredbones | benji, by "instance" do you mean, did I run mkzopeinstance? I did but I deleted everthing of the old system. | 22:05 |
benji | what does "deleted everthing of the old system" mean, specifically? | 22:06 |
tiredbones | I deleted all directories and change my PYTHONPATH variable to point to the new install. | 22:07 |
benji | what does "deleted all directories" mean, specifically? :/ | 22:08 |
tiredbones | benji, My sys.path pointed to all the new istalled system. | 22:09 |
benji | you made PYTHONPATH point to the instance or to the installed zope 3? | 22:09 |
tiredbones | benji, Yes,I made it point to zope3. I had is point to /usr/local/Zope-3.1.0c1. | 22:10 |
tiredbones | benji, I did not have it point to the instance. | 22:11 |
benji | ok, we're not communicating well. :) Start from scratch, following the instructions in the quick start and you should be OK. | 22:11 |
tiredbones | benji, I'm doing that now, but I'm wondering why the old still picked up my first install of Zope after I changed and deleted my first install of Zope 3. | 22:14 |
tiredbones | s/still/installes/ | 22:14 |
tiredbones | I'll let it go for now, benji. thanks for your help. | 22:16 |
benji | NP, tiredbones, good luck | 22:17 |
tiredbones | I'm going to need alot of luck. | 22:18 |
*** tiredbones has left #zope3-dev | 22:25 | |
*** tiredbones has joined #zope3-dev | 22:31 | |
*** natea|away has quit IRC | 22:32 | |
*** tiredbones has quit IRC | 22:34 | |
*** ignas has quit IRC | 22:44 | |
*** tarek_ has quit IRC | 22:45 | |
*** tarek_ has joined #zope3-dev | 22:47 | |
*** baldtrol has left #zope3-dev | 22:59 | |
q[monty] | is there a new Zope3 way to get context/absolute_url - or a different way I should do that same thing? | 23:01 |
*** Aiste has quit IRC | 23:02 | |
srichter | no, this is the way | 23:03 |
q[monty] | It would probably help if my object that was context actually inherited from something, wouldn't it. | 23:03 |
mgedmin | context/@@absolute_url | 23:03 |
mgedmin | I do not think it will work without the @@ | 23:04 |
*** mgedmin has quit IRC | 23:06 | |
q[monty] | it helps if I write my tal:attributes statement right. :) | 23:08 |
*** efge has joined #zope3-dev | 23:09 | |
q[monty] | now I'm getting TraversalError - do I need to grant permission to something new to be allowed to call absolute_url? | 23:09 |
srichter | what does the traceback say? | 23:10 |
q[monty] | TraversalError: (<zpress.ZPress.ZPress instance at 0x4112db6c>, 'absolute_url') | 23:10 |
q[monty] | I can past more of it if you want... | 23:11 |
srichter | try context/@@absolute_url then | 23:11 |
JoaoJoao | srichter: I got the IPrincipalCreate thing | 23:14 |
q[monty] | that worked... what's the difference | 23:14 |
q[monty] | ? | 23:14 |
srichter | you specifically request the view absolute)url | 23:14 |
srichter | it seems that the TALES namespace does not automatically do that | 23:15 |
srichter | JoaoJoao: great | 23:15 |
q[monty] | srichter, so I could, for sake of arguement, declare absolute_url as a view for my class in zcml and then not use the @@, right? | 23:17 |
*** alienoid has joined #zope3-dev | 23:17 | |
srichter | no | 23:18 |
JoaoJoao | srichter: However, I tried to use IPrincipalROleManager to assign roles to the user, but it's not working, I'm not sure if I'm doing it right | 23:19 |
srichter | JoaoJoao: the SchoolTool project uses all those APIs all the time, so you might want to look there | 23:20 |
JoaoJoao | good to know, thanks | 23:20 |
*** deo has quit IRC | 23:32 | |
*** deo has joined #zope3-dev | 23:32 | |
*** JoaoJoao has quit IRC | 23:40 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!