| J1m | the main difference with content providers seems to be dispatch on the view as well as the content and the request, but the example doesn't really dispatch on the view. | 00:00 |
|---|---|---|
| srichter | right | 00:00 |
| srichter | I have examples, but I did not include a test case | 00:01 |
| srichter | actually dispatching on views will be very rare, I think | 00:01 |
| J1m | The other motivation seems to be integration with tal, but this doesn't get me very excited. :) | 00:01 |
| srichter | I was thinking about removing it as part of the discriminator | 00:01 |
| J1m | well, then how is this different from other sort of view lokup for subviews or subforms? | 00:01 |
| J1m | lookup | 00:01 |
| srichter | well, TAL integration is very important, since we do not want o alienate this universe | 00:01 |
| srichter | well, it is different in the sense that it can be configured, which is different from TAL macros, for example | 00:02 |
| srichter | I agree, content providers themselves don't add much juice | 00:02 |
| srichter | it's the code that will be built on top of it | 00:02 |
| J1m | well, right, but i'm increasingly in favo of pushing information to tal, rather than pullting data from it. | 00:03 |
| srichter | like viewlets, portlets, etc | 00:03 |
| srichter | all I want with CP is to provide a clean interface to TAL, so people can use both | 00:03 |
| srichter | which I think is a very desirable goal | 00:04 |
| J1m | Roger seems to be dissowning viewlets. :) | 00:04 |
| srichter | the other extreme is Jean-Marc's CPS skin, which totally turns off TAL and does only a very convoluted Python call in a page template | 00:04 |
| srichter | I certainly do not want this use case either | 00:04 |
| J1m | I guess I want to see tal, and especialy tales be less powerful, not more powerful. | 00:04 |
| srichter | it does not make TAL more powerful | 00:05 |
| J1m | It moves more computation there. | 00:05 |
| srichter | in fact it asks users to not use TAL for page cosntruction based on page segments | 00:05 |
| srichter | no | 00:06 |
| srichter | I don | 00:06 |
| srichter | I don't consider the TALES namespace as part opf TAL | 00:06 |
| J1m | In fact, we've found the update/render dance to be critical for page composition, and this isn't really supported well by tal. | 00:06 |
| srichter | right, I noticed that while reading through Gary's E-mail today | 00:06 |
| J1m | You really want to control this sort of thing from python. | 00:06 |
| J1m | we still use zpt, but, increasingly, it's zpt that is called from Python. | 00:07 |
| srichter | right, viewlets does this too | 00:07 |
| *** BjornT_ has quit IRC | 00:08 | |
| J1m | we would typically do the lookup of subpaged in Python and then render the assembly in zpt. | 00:08 |
| srichter | it calls ZPT from Python to constrcut segments of the page | 00:08 |
| *** BjornT has joined #zope3-dev | 00:08 | |
| srichter | right, liek viewlets | 00:08 |
| J1m | like the viewlet manager. Right. | 00:09 |
| *** GaryPoster has joined #zope3-dev | 00:09 | |
| srichter | in other words, the content provider package is the interface between the old way of using page templates and the new way | 00:09 |
| srichter | and this is really important to me specifically | 00:10 |
| srichter | since in schooltool we want to migrate slwoly, if ever completely | 00:10 |
| *** efge has joined #zope3-dev | 00:10 | |
| J1m | well, it's an interface. | 00:10 |
| GaryPoster | (Jim is proxying for me, afaik ;-) I'm just hanging out) | 00:10 |
| J1m | Almost everyone agrees that we want to make less use of macros. | 00:10 |
| srichter | in schooltool, we currently can't distribute packages separately, because UI components are intermixed between views | 00:11 |
| srichter | so my main goal is to be able to define "hooks" in TAL that allow me to insert content by configuration | 00:12 |
| srichter | so my goal is the componentization of the UI | 00:12 |
| srichter | (note that I have no need or interest right now for portlet-level features) | 00:12 |
| J1m | But why should it be hooks in tal? | 00:12 |
| srichter | because all of our views are written in TAL | 00:12 |
| J1m | I would argue that you should assemble in python and render the assembly in tal. | 00:13 |
| J1m | They should be writtedn in Python. :) | 00:13 |
| srichter | that means I would have to touch the entire code base to gain that benefit | 00:13 |
| srichter | this is not possible | 00:13 |
| srichter | and for simple things I really like writing full page templates and just inserting some hooks | 00:14 |
| J1m | ok | 00:14 |
| srichter | think of content providers as of Five in the context of Zope 2 and 3 :-) | 00:15 |
| srichter | btw, we should ask Roger for some links concerning definitions ;-) | 00:18 |
| srichter | still there? | 00:19 |
| J1m | yup | 00:19 |
| srichter | I guess you are having internal discussion, so I wait ... | 00:19 |
| J1m | no | 00:19 |
| J1m | I just have no response to you. :) | 00:20 |
| *** hazmat has joined #zope3-dev | 00:21 | |
| srichter | ok | 00:21 |
| srichter | (it's just so strange that you don;t have a response ;-) | 00:22 |
| *** BjornT_ has joined #zope3-dev | 00:25 | |
| *** zbir has quit IRC | 00:32 | |
| *** efge has quit IRC | 00:33 | |
| *** efge has joined #zope3-dev | 00:34 | |
| *** efge has joined #zope3-dev | 00:35 | |
| *** projekt01 has joined #zope3-dev | 00:36 | |
| *** BjornT has quit IRC | 00:37 | |
| projekt01 | J1m, srichter, I was reading the discussion on the log about viewlets. | 00:49 |
| projekt01 | All I can say right now is, don't see the TALES implementation as the common way to use viewlets. It's just the TAL integration part. | 00:49 |
| projekt01 | The implementation of content provider and viewlets depends only on the adapter concept. Nothing more, the TALES expression is more like one way to call them. | 00:51 |
| srichter | right, though we really need to address the update/render bug Gary described; I do have an idea on how to do this though | 00:52 |
| projekt01 | We dont' have this bug in our concept. | 00:53 |
| srichter | because we have not addressed it yet | 00:53 |
| GaryPoster | Hi Roger. And if you rip out the TALES expression approach, then the content provider code basically just defines an ability to lookup on the basis of view, in addition to context and request, right? Which in itself can use the update/render pattern of the subview stuff just fine, as far as I can see. | 00:53 |
| J1m | as long as you don't use it from TAL. :) | 00:54 |
| srichter | right | 00:54 |
| GaryPoster | Right, that's what I meant | 00:54 |
| projekt01 | I'm not sure right now. I guess we have a problem in defining what all this concepts are. | 00:54 |
| srichter | I guess we cannot address this problem, if you use TAL traditionally | 00:55 |
| projekt01 | Let me explain it a little, | 00:55 |
| projekt01 | A portlet in ava JSR 168 is a standalone application. right? | 00:55 |
| srichter | another method would be to have the View class collect all content providers beforehand | 00:55 |
| GaryPoster | (Sadly I will have to leave in about five minutes). projekt01: yes. srichter: yes. | 00:56 |
| projekt01 | I guess we try to integrate them to much right now. There is no way to render errors across the portlet and the view | 00:56 |
| projekt01 | Each of them have a own error handling | 00:56 |
| projekt01 | Or if not we don't speak about JSR 168 portlets. | 00:57 |
| projekt01 | They share nothing, really nothing! | 00:57 |
| projekt01 | Portlets can run on other server too. | 00:58 |
| GaryPoster | If you simply say that you avoid the problem by not allowing any viewlet to ever possibly integrate with one another, even by modifying the same content object, then you son't need to worry about the update/render problem. That's really a lot more constrained than we want to be (or have had to be for client projects). | 00:58 |
| srichter | projekt01: I think we are not only talking about JSR-168-style portlets here, but more generally about a new way of composing pages | 00:58 |
| GaryPoster | srichter: yes. | 00:59 |
| projekt01 | srichter, yes, but then we speak about something like (super) widgets ;-) | 00:59 |
| srichter | right, exactely | 00:59 |
| projekt01 | And not about viewlets, viewlets are "additional" content providers. They never know the enviroment. | 00:59 |
| srichter | we are talking about a generalization of widgets | 00:59 |
| J1m | for us, it was initially sub-forms. | 01:00 |
| J1m | of which widgets are a special case. | 01:00 |
| projekt01 | Yes, that's the base of the subview concept. | 01:00 |
| projekt01 | J1m, yes, that's a good concept but has not much to do with viewlets or portlets in our definition. | 01:01 |
| J1m | It has a lot to do with jsr168 portlets | 01:01 |
| J1m | where a portlet can update data that is rendered by other portlets. | 01:02 |
| *** BjornT has joined #zope3-dev | 01:02 | |
| projekt01 | No, I think subviews try to solve only the restriction of nested HTML forms | 01:02 |
| projekt01 | btw, I think statefull portlets and subviews are not a good combination. | 01:02 |
| J1m | This is based on a lot of experience implementing a portlet system, as well as with complex forms. | 01:02 |
| J1m | (BTW, we plan to release the portlet system.) | 01:02 |
| projekt01 | Cool | 01:03 |
| GaryPoster | I've got to go guys. Have a good night. | 01:03 |
| J1m | projekt01, they address the situation that components of a page may have update responsibilities. | 01:03 |
| *** GaryPoster has quit IRC | 01:03 | |
| projekt01 | J1m, but remember portlets provide a own url, they are not callable itself at this url and should run on every server without have dependency to other parts. | 01:04 |
| projekt01 | Portlets are standalone applications! | 01:04 |
| J1m | as Gary said, that is too restrictive in our experience. | 01:05 |
| projekt01 | J1m, I think every other concept is really Ok. But don't call them portlet since portlet are very known and very good defined. | 01:06 |
| projekt01 | I just telling don't call another concept portlet. | 01:07 |
| J1m | the concept I'm talking about is portlets. | 01:07 |
| projekt01 | J1, I agree I you say the UI concept | 01:09 |
| projekt01 | J1m, I agree I you say the UI concept | 01:09 |
| projekt01 | Or if you share error handling fro views and portlets, how can you share them if a portlet runs on another server? | 01:10 |
| J1m | Our portlets all run in the same server. | 01:11 |
| J1m | Often multiple portlets display (some aspect of) the same content. | 01:11 |
| J1m | User' | 01:11 |
| J1m | User's expect the displays to be consistent. | 01:11 |
| *** BjornT__ has joined #zope3-dev | 01:11 | |
| J1m | They expect that if they update data in one portlet, the change will be relected in another. | 01:12 |
| projekt01 | J1m, I see all your usecases and I agree it's nice to have them. But portlets do not share something. We really should not use well defined names for anther concept. I guess we will confuse people with a good understanding of common patterns. | 01:14 |
| J1m | I should let you and Brian Lloyd argue about what a "portlets" are. | 01:15 |
| J1m | I should let you and Brian Lloyd argue about what "portlets" are. | 01:15 |
| projekt01 | ;-) | 01:15 |
| J1m | BTW, can you give a reference for the definition of content provider as used in Java? | 01:16 |
| * projekt01 is searching for a link | 01:17 | |
| *** BjornT___ has joined #zope3-dev | 01:17 | |
| J1m | This should go in the content provider README.txt. | 01:17 |
| *** BjornT_ has quit IRC | 01:19 | |
| projekt01 | J1m, I only found a link to the protlet builder app from sun this quick. It's a presentation movie which explains the portlet concept a little bit. | 01:20 |
| projekt01 | http://access1.sun.com/Video_Tutorials/PB/PB-1.html | 01:20 |
| mp | so, did my zca make its way to zope corp? | 01:21 |
| J1m | If you can find a better link later, it would be god to have it in the README.txt. | 01:21 |
| *** BjornT_ has joined #zope3-dev | 01:22 | |
| mp | I guess I might have to resend it :/ | 01:22 |
| J1m | mp, I haven't seen it. | 01:22 |
| J1m | It would be good to just email it to me. | 01:22 |
| projekt01 | J1m, I have to update our project tomorrow, but I will work on this at wednesday till we have a good solution ;-) | 01:23 |
| mp | I didn't scan it, don't have time to buy/borrow scanner or to visit friend :/ | 01:23 |
| J1m | :( | 01:24 |
| J1m | I have an extra scanner if you want it. :) | 01:24 |
| mp | Ok, but please don't send it via simple s-mail, it might not reach me | 01:24 |
| J1m | I'll scan it and email it to you. | 01:25 |
| *** andres has quit IRC | 01:25 | |
| *** BjornT_ has quit IRC | 01:25 | |
| projekt01 | J1m, Ok, I send you a better doc if I work on this part again an check the subview concept ;-) I guess I write the main idea down first, so we understand what each concept tries to do ;-) | 01:25 |
| *** andres_ has joined #zope3-dev | 01:25 | |
| J1m | BTW, forget persistent views. :) | 01:26 |
| *** strichter has joined #zope3-dev | 01:26 | |
| *** BjornT_ has joined #zope3-dev | 01:27 | |
| *** srichter has quit IRC | 01:27 | |
| projekt01 | Ok, isn't that a model-view-controller all in one in instance ;-) | 01:27 |
| J1m | exactly | 01:28 |
| *** strichter is now known as srichter | 01:28 | |
| *** ChanServ sets mode: +o srichter | 01:28 | |
| projekt01 | I guess persistent views are a bad idea then that's nothing more the to have th model in the view which is also a controller. | 01:28 |
| projekt01 | ;-) | 01:28 |
| mp | hm, I could then print it | 01:28 |
| J1m | I've always had a lot of trouble with controllers. | 01:29 |
| J1m | mp, hopefully your snail mail copy will get here soon. | 01:29 |
| *** BjornT has quit IRC | 01:29 | |
| J1m | I've heard it takes a long time to get paper from Europe to the US. I don't know why. | 01:29 |
| srichter | with air mail it is pretty consistently 5 days from germany | 01:30 |
| projekt01 | J1m, I think separate controllers are the only good way to build big applications. I have really some problems where I could easy solve with a own controller. | 01:31 |
| projekt01 | Right now we try everything to solve in the views, which ends in such complex API's like the formlib. ( I like it, but many people have problem to understand them) | 01:32 |
| projekt01 | I guess a controller should be responsible for the update task and the view for the presentation task. | 01:32 |
| J1m | every time I see controllers and views presented, the controllers and views are tightly linked and the end result looks more complicated. | 01:33 |
| projekt01 | I really scary about the idea to implement patterns for a pipline or layout engine if they also have to go into the view which implements the formlib API too. | 01:34 |
| projekt01 | Yes, we found a good way to use views but the will become to complex. And uhaaa if they should also handle the portlet request.... | 01:35 |
| projekt01 | It really blows my brain sometime away ;-) | 01:35 |
| *** BjornT__ has quit IRC | 01:35 | |
| projekt01 | I really like to separate them (views, portlets, viewlets, widgets, pipelines) in more easy understandable parts. | 01:36 |
| J1m | I'd be interested to see a proposal that motivates the separation of controller and view. | 01:36 |
| projekt01 | Right now the view class is our single API for all implementations. | 01:36 |
| J1m | me too | 01:36 |
| J1m | well, no more than the command line is the single api for all unix applications. | 01:37 |
| *** BjornT___ has quit IRC | 01:37 | |
| *** BjornT has joined #zope3-dev | 01:37 | |
| J1m | that isn't quite right | 01:37 |
| J1m | views are low level building blocks. | 01:37 |
| J1m | They can be used with lots of apis. | 01:38 |
| J1m | If you think separating controllers and views would help, I'm all ears. | 01:38 |
| J1m | But I;d like to see concrete examples that support the case. | 01:38 |
| J1m | But I have to go leave at the moment. :) | 01:38 |
| projekt01 | Ok, on unix I can do everything with 50 commands, but only because the hole unix is defined in one view ;-) | 01:39 |
| projekt01 | only good separation of components allows you to develop simply applications | 01:40 |
| projekt01 | J1m, see you soon | 01:40 |
| *** J1m has quit IRC | 01:40 | |
| *** natea|away is now known as natea | 01:40 | |
| *** projekt01 is now known as projekt01_ | 01:41 | |
| *** projekt01_ is now known as _projekt01 | 01:41 | |
| *** _projekt01 is now known as projekt01 | 01:42 | |
| *** projekt01 is now known as _projekt01 | 01:48 | |
| *** _projekt01 is now known as projekt01 | 01:48 | |
| *** zbir has joined #zope3-dev | 01:53 | |
| *** BjornT_ has quit IRC | 01:54 | |
| *** BjornT has quit IRC | 02:03 | |
| *** philiKON has joined #zope3-dev | 02:10 | |
| *** zbir has quit IRC | 02:12 | |
| *** stub has joined #zope3-dev | 02:30 | |
| *** newpers_ has joined #zope3-dev | 02:35 | |
| philiKON | newpers_, thanks for the typo hint the other day | 02:36 |
| newpers_ | :) np | 02:36 |
| *** efge has quit IRC | 02:40 | |
| *** tiredbones has quit IRC | 03:06 | |
| *** hazmat has quit IRC | 03:17 | |
| *** projekt01 has quit IRC | 03:25 | |
| *** roym has quit IRC | 03:38 | |
| *** stub has quit IRC | 03:39 | |
| *** xenru has joined #zope3-dev | 03:41 | |
| *** xenru is now known as xenru|away | 03:46 | |
| *** stub has joined #zope3-dev | 04:08 | |
| *** niemeyer has quit IRC | 05:12 | |
| *** newpers_ has quit IRC | 06:24 | |
| *** newpers has joined #zope3-dev | 06:26 | |
| *** deo has quit IRC | 07:14 | |
| *** kaczordek has joined #zope3-dev | 07:24 | |
| *** whit has quit IRC | 07:35 | |
| *** whit has joined #zope3-dev | 07:36 | |
| *** whit is now known as whit|zZzz | 08:05 | |
| *** whit|zZzz has quit IRC | 08:06 | |
| *** whit has joined #zope3-dev | 08:08 | |
| *** dobee has joined #zope3-dev | 08:10 | |
| *** sashav has quit IRC | 08:27 | |
| *** BjornT has joined #zope3-dev | 08:28 | |
| *** natea is now known as natea|zZz | 08:30 | |
| *** MacYET has joined #zope3-dev | 08:47 | |
| *** stub has quit IRC | 08:53 | |
| * MacYET is away: lesen hilft. | 09:09 | |
| *** einheit has joined #zope3-dev | 09:17 | |
| *** einheit is now known as SteveA_ | 09:19 | |
| *** hdima has joined #zope3-dev | 09:21 | |
| *** Soulraven has joined #zope3-dev | 09:41 | |
| *** MJ has quit IRC | 09:43 | |
| *** sashav has joined #zope3-dev | 09:54 | |
| *** sashav_ has joined #zope3-dev | 10:00 | |
| *** sashav has quit IRC | 10:00 | |
| *** sashav_ is now known as sashav | 10:00 | |
| *** tekNico has joined #zope3-dev | 10:12 | |
| *** tekNico has left #zope3-dev | 10:13 | |
| *** newpers has quit IRC | 10:28 | |
| *** tarek has joined #zope3-dev | 10:32 | |
| sashav | good morning, where can I see examples of schemas where one field should be a instance from a factory and I choose the factory when I add my object? | 10:33 |
| MacYET | in theory there might be a doctest :) | 10:35 |
| Theuni | hmm. is dtml re-implemented or ported in zope3? | 10:40 |
| * Theuni just found a bug in the Zope 2 dtml that he doesn't want to fix | 10:41 | |
| MacYET | ignoe it | 10:43 |
| Theuni | doing that | 10:45 |
| Theuni | workaround is available ... | 10:46 |
| Theuni | it's just _nasty_ | 10:46 |
| VladDrac | dtml is nasty | 10:51 |
| *** zagy has joined #zope3-dev | 10:52 | |
| *** zagy has joined #zope3-dev | 10:53 | |
| *** mgedmin has joined #zope3-dev | 10:59 | |
| sashav | MacYET: you have this theory written down somewhere? :) | 10:59 |
| *** stub has joined #zope3-dev | 11:05 | |
| VladDrac | sasha you want to select the factory to create your object upon object creation? | 11:14 |
| *** kaczordek has quit IRC | 11:24 | |
| *** MJ has joined #zope3-dev | 11:25 | |
| sashav | MyObject can have one instance of object2 or object3 which have IObject2 and IObject3 deriveded from IObjectCommon how can I create the scema for MyObject, VladDrac ? | 11:26 |
| sashav | s/which have/which implement | 11:26 |
| VladDrac | folderish/containerish using constrains? | 11:31 |
| sashav | MyObject doesn¨t have to be folderish, IObjectCommon will be a rdflibgraph | 11:33 |
| sashav | or any interface derived from IObjectCommon will be a rdflib.graph | 11:33 |
| sashav | well really it's like this :) | 11:34 |
| sashav | depending on which IObjectX schema you choose you will get a different MyObject with a configured rdflib.graph | 11:34 |
| *** andres_ is now known as andres | 11:35 | |
| andres | Its not possible to add something to two menus in <page menu=""> or? | 11:35 |
| mgedmin | what an marvelously indecipherable question | 11:42 |
| VladDrac | I'm not sure if I understand what you want | 11:50 |
| VladDrac | but afaik the Z3MI is built upon containers/containment | 11:50 |
| VladDrac | which would mean your objects have to be containers as well. If that doesn't work for you, you can always build your own forms on top of it | 11:51 |
| VladDrac | i.e. using zope.formlib | 11:51 |
| * VladDrac 's currently doing exactly that with Zope3 / formlib / sqlobject | 11:51 | |
| andres | No, what i mean is more simple i think. I just want a <page> appear in two different menus. | 11:52 |
| andres | And i want to know, if i have to use seperate <menuitem>'s for that, or if i can use menu="" in <page> | 11:53 |
| VladDrac | I was actually talking about sashav's problem :) | 11:53 |
| mgedmin | andres, you can specify only one menu="" in <page> | 11:54 |
| mgedmin | and then you can specify as many <menuitem> as you wish | 11:54 |
| andres | ok, thats what i tought. | 11:54 |
| *** baiju has joined #zope3-dev | 11:56 | |
| sashav | can I add content types and tabs to zope 2.8.1 with five? | 12:00 |
| sashav | to the ZMI | 12:00 |
| *** Alef has joined #zope3-dev | 12:04 | |
| MacYET | sure | 12:04 |
| sashav | where can I find that theory MacYET , I have looked and not seen any tests or examples that work, the nearest that should work was simplecontent in Five1.1/testing but doing that in my stuff didn't make any diff | 12:05 |
| *** baiju has quit IRC | 12:07 | |
| MacYET | e.g. look at TXNG3 | 12:09 |
| *** klaus has joined #zope3-dev | 12:11 | |
| *** bob2 has joined #zope3-dev | 12:15 | |
| *** zagy has quit IRC | 12:24 | |
| Soulraven | Any Zepp experts present? | 12:27 |
| sashav | MacYET: quick Q, do you know how I can add a tab that points to browser:editform which uses a schema to generate the form? in txng3 you only use templates as far as I can see | 12:28 |
| sashav | I have a class1: implements I1 and in zcml I have that class1 implements I2 and browser:addform for I2 with factory that produces class1() but I don't get the args from I2 into my factory, why? | 12:45 |
| *** SteveA_ has quit IRC | 12:46 | |
| *** mkerrin has joined #zope3-dev | 12:53 | |
| *** xenru|away has quit IRC | 12:58 | |
| sashav | when is the attribute from I2 set on my object? I tried to subscribe to ObjectAddedEvent but it still wasn't there but if I go debug into my zope the persistent object has the I2 attribute | 13:00 |
| srichter | sashav: tab: just declare the menu in your editform directive; this is pretty much covered in any beginner documentation, including the books | 13:29 |
| sashav | srichter: for z2.8? | 13:30 |
| srichter | please do not ask Zope 2.8 questions here | 13:31 |
| sashav | ya ya it was z3 Q running on z2.8 | 13:33 |
| srichter | then ask the question in the Five form | 13:35 |
| srichter | then ask the question in the Five forum | 13:35 |
| *** srichter has quit IRC | 13:36 | |
| philiKON | sashav, five has no ZMI capabilities | 13:39 |
| philiKON | if you want to add that to five, be my guest | 13:40 |
| sashav | ok, :) | 13:40 |
| philiKON | but i don't think a lot of people need to use the zope 2 zmi as it is | 13:40 |
| philiKON | most five integrations happen on a higher level | 13:40 |
| sashav | anyone who can enlighten me on my interface and attr setting issue? | 13:40 |
| philiKON | OTOH, it might be useful looking into fivifying the zope 2 zmi so that it becomes a mere skin | 13:41 |
| philiKON | interface and attr setting? | 13:41 |
| sashav | when is the attribute from I2 set on my object? I tried to subscribe to ObjectAddedEvent but it still wasn't there but if I go debug into my zope the persistent object has the I2 attribute | 13:41 |
| sashav | have a class1: implements I1 and in zcml I have that class1 implements I2 and browser:addform for I2 with factory that produces class1() but I don't get the args from I2 into my factory, why? | 13:41 |
| philiKON | look at set_before_add | 13:42 |
| philiKON | page 397 in my book | 13:42 |
| sashav | oh :) thnx | 13:43 |
| sashav | ok when is it set when I don't have this option? and who sets it because it is set | 13:43 |
| philiKON | the AddForm machinery sets the stuff | 13:44 |
| *** J1m has joined #zope3-dev | 13:44 | |
| philiKON | question is whether it sets it before adding the object to the container or afterwards | 13:44 |
| *** Aiste has joined #zope3-dev | 13:56 | |
| *** ignas_ has joined #zope3-dev | 14:04 | |
| *** Soulraven has quit IRC | 14:07 | |
| *** Soulraven has joined #zope3-dev | 14:10 | |
| VladDrac | after | 14:12 |
| VladDrac | unless you define ehm.. | 14:12 |
| VladDrac | set_before_add | 14:13 |
| VladDrac | <browser:addform | 14:13 |
| VladDrac | label="Add News" | 14:13 |
| VladDrac | name="AddNews.html" | 14:13 |
| VladDrac | schema="cubic.types.interfaces.INews" | 14:13 |
| VladDrac | content_factory="cubic.types.news.News" | 14:13 |
| VladDrac | permission="zope.ManageContent" | 14:13 |
| VladDrac | set_before_add="title" | 14:13 |
| VladDrac | /> | 14:14 |
| Soulraven | \^_^ | 14:16 |
| philiKON | VladDrac, yes, *I* know that they're set after... this was more a rhetorical question for sashav :) | 14:20 |
| *** zbir has joined #zope3-dev | 14:20 | |
| VladDrac | no you don't! I'm smarter than you when it comes to zope3! | 14:21 |
| VladDrac | oh wait no I completely suck :) | 14:21 |
| VladDrac | philikon: it was more meant as a tip for sashav | 14:21 |
| philiKON | it could very well be that you know more, i've forgotten so much already :) | 14:21 |
| philiKON | i look up stuff in my book too... and then i think "i wrote that? i used to know that?!?" | 14:22 |
| *** zbir has quit IRC | 14:22 | |
| VladDrac | hehe :) | 14:22 |
| *** zbir has joined #zope3-dev | 14:22 | |
| *** J1m has quit IRC | 14:23 | |
| sashav | :) | 14:25 |
| *** stub has quit IRC | 14:26 | |
| *** stub has joined #zope3-dev | 14:26 | |
| *** efge has joined #zope3-dev | 14:32 | |
| *** klaus has quit IRC | 14:33 | |
| *** niemeyer has joined #zope3-dev | 14:46 | |
| *** zbir has quit IRC | 14:46 | |
| *** tarek has quit IRC | 14:53 | |
| *** srichter has joined #zope3-dev | 14:53 | |
| *** srichter has quit IRC | 14:53 | |
| *** tarek has joined #zope3-dev | 14:53 | |
| *** srichter has joined #zope3-dev | 14:54 | |
| *** Lewy has joined #zope3-dev | 14:54 | |
| Lewy | hi, why I don't have app.workflow in my installation? I installed from the bundle Zope-3.1.0.win32-py2.3.exe | 14:55 |
| *** ChanServ sets mode: +o srichter | 14:56 | |
| srichter | Lewy: because we are not distributing it | 14:56 |
| srichter | in fact, it will never be distributed | 14:56 |
| srichter | every serious Zope 3 player is using zope.wfmc and zope.app.wfmc | 14:57 |
| Lewy | srichter: hmm, do you recognize? ;) "20.1 Step I: Making your Message Workflow aware" | 14:59 |
| srichter | of course, but I also write that you have to install this separate package | 15:02 |
| srichter | zope.wfmc did not exist back then | 15:02 |
| bob2 | is there a list somewhere of what package-includes/ files do what? | 15:09 |
| bob2 | some are clearly optional, while some seem to be essential | 15:09 |
| srichter | bob2: none of the package-includes should be essential; this would be a bug | 15:13 |
| bob2 | I mean, essential to normal use | 15:25 |
| bob2 | say, running messageboard | 15:25 |
| bob2 | or is it a bug for any of them to be needed? | 15:25 |
| *** ignas_ has quit IRC | 15:33 | |
| srichter | ahh, yes, the message board requires some of the optional but by default activated packages | 15:37 |
| srichter | it just depends on what you want to do with all of this | 15:38 |
| *** mgedmin has quit IRC | 15:38 | |
| srichter | I would try to turn on and off packages to see what you need. | 15:38 |
| *** benji has joined #zope3-dev | 15:44 | |
| *** natea has joined #zope3-dev | 15:45 | |
| *** Soulraven has quit IRC | 15:45 | |
| *** tarek has quit IRC | 15:46 | |
| *** vlado has joined #zope3-dev | 15:55 | |
| *** zbir has joined #zope3-dev | 15:58 | |
| *** regebro has joined #zope3-dev | 16:01 | |
| *** natea|zZz has quit IRC | 16:05 | |
| *** jinty has joined #zope3-dev | 16:18 | |
| *** natea has quit IRC | 16:24 | |
| *** natea has joined #zope3-dev | 16:24 | |
| *** natea_ has joined #zope3-dev | 16:31 | |
| *** stub has quit IRC | 16:35 | |
| *** natea_ has quit IRC | 16:40 | |
| *** MacYET has quit IRC | 16:43 | |
| *** benji has quit IRC | 16:51 | |
| *** natea has quit IRC | 16:56 | |
| *** Lewy has quit IRC | 17:02 | |
| *** natea has joined #zope3-dev | 17:03 | |
| *** Alef has quit IRC | 17:05 | |
| *** stub has joined #zope3-dev | 17:07 | |
| sashav | I have two schemas = two addforms on submit they should generate a configured object from an 3rd interface how do I configure that? should I use a factory and an adapter or how? now I have :addform schema='IMySchema1' content_factory="MyClassImplementing3rd" that doesn't work because the factory returns an not adoptable interface | 17:11 |
| *** xenru|away has joined #zope3-dev | 17:19 | |
| *** natea is now known as natea|away | 17:21 | |
| *** benji has joined #zope3-dev | 17:24 | |
| srichter | hdima: I think your PasswordManager idea is cool | 17:32 |
| srichter | hdima: so if you want to merge that into the trunk, that's fine with me | 17:33 |
| srichter | hdima: I would really like to support those managers inside the mkzopeinstance, even if we are not using the CA for it | 17:33 |
| hdima | Ok, now I want to finish ++lang++ and then start working on PasswordMangers... | 17:34 |
| *** zagy has joined #zope3-dev | 17:34 | |
| srichter | ok, great | 17:35 |
| *** xenru|away is now known as xenru | 17:35 | |
| srichter | don't forget; the deadline is November 1st ;-) | 17:35 |
| hdima | yes, just realize that :) | 17:35 |
| *** SteveA_ has joined #zope3-dev | 17:36 | |
| *** niemeyer is now known as nie_lunch | 17:37 | |
| *** hdima has quit IRC | 17:41 | |
| *** natea|away is now known as natea | 17:48 | |
| *** philiKON has quit IRC | 17:53 | |
| *** JoaoJoao has joined #zope3-dev | 18:00 | |
| JoaoJoao | hello | 18:00 |
| MJ | srichter: ping | 18:06 |
| MJ | srichter: I was looking into subscription adapters | 18:07 |
| MJ | What problem are they designed to solve? | 18:07 |
| MJ | Listing multiple adaptations to an interface? | 18:07 |
| srichter | MJ: pong | 18:08 |
| *** kbremer has joined #zope3-dev | 18:09 | |
| srichter | MJ: no, they are used to implement event subscriptions | 18:09 |
| srichter | so when an event is triggered, you simply look up all adapters for this event | 18:10 |
| MJ | exactly :) | 18:10 |
| MJ | Easy listing of all adapters ;) | 18:10 |
| srichter | since those adapters have the same discriminator and no name, we cannot use regular adapters | 18:10 |
| MJ | Ah | 18:10 |
| srichter | no, it will not list all adapters | 18:10 |
| MJ | List all adapters for a given interface I ment, sorry | 18:11 |
| srichter | use adapters.getAdaptersFor(obj) for example | 18:11 |
| MJ | Yes, that's a list as well | 18:11 |
| srichter | mmh, that is a slipery road, since subscription adapters are differently stored than the regular ones | 18:11 |
| MJ | So, why can't that be used for events? | 18:11 |
| srichter | because then you would have to name the adapters | 18:11 |
| MJ | Yes, the implementation differs | 18:11 |
| srichter | here is an example | 18:12 |
| srichter | adapters.register(I1, Interface, Foo1) | 18:12 |
| srichter | adapters.register(I1, Interface, Foo2) | 18:12 |
| srichter | would result in one registration, since Foo1's is overridden by Foo2's | 18:12 |
| srichter | but | 18:12 |
| *** mp has quit IRC | 18:13 | |
| MJ | Right | 18:13 |
| srichter | adapters.subscribe(I1, Interface, Foo1) | 18:13 |
| srichter | adapters.subscribe(I1, Interface, Foo2) | 18:13 |
| MJ | So subscriberAdapters allow for multiple adaptions | 18:13 |
| srichter | would result in two adapter registrations | 18:13 |
| srichter | both of which would not override the above one | 18:13 |
| MJ | while (regular) adapters are only for one | 18:13 |
| MJ | You can only 'multiplex' the adapters when you name them | 18:13 |
| MJ | Clear | 18:13 |
| MJ | Thanks! | 18:14 |
| srichter | "multiple adaptations" is a bad term, since multi-adapters are something else :-) | 18:14 |
| srichter | right | 18:14 |
| MJ | So, the problem solved is that subscribers can exist nameless and without interfering | 18:14 |
| srichter | yes | 18:15 |
| MJ | while regular adapters must be unique, although names can be used to differentiate. | 18:15 |
| MJ | Clear. | 18:15 |
| MJ | Registering another adapter under the same name (blank or otherwise) overrides | 18:15 |
| *** mp has joined #zope3-dev | 18:15 | |
| MJ | Registering another subscriber adds to the list. | 18:15 |
| *** lurker has joined #zope3-dev | 18:16 | |
| srichter | yes | 18:16 |
| srichter | I think you got it :-) | 18:17 |
| MJ | the problem that brought this up: | 18:18 |
| MJ | We have UML 2.0 object model | 18:18 |
| MJ | and want to expose certain categories of attributes in GUI tabs | 18:18 |
| MJ | So there are tabbed views on the model; multiple tabs per interface | 18:19 |
| MJ | I am suggesting using named adapters though | 18:19 |
| MJ | Easy to list all named adapters. | 18:19 |
| srichter | yes, it is | 18:19 |
| srichter | we do this with utilities all the time | 18:19 |
| srichter | list all available SQL connections for example | 18:19 |
| MJ | Yup | 18:21 |
| MJ | So the 'documentation' tab for all UML elements can then be overridden | 18:22 |
| MJ | While if that tab was a subscriber, you'd get 2 documentation tabs | 18:22 |
| MJ | Not what you want. | 18:22 |
| srichter | right | 18:22 |
| MJ | So, when is the next sprint :) | 18:23 |
| MJ | (Sorry I missed the last one in Germany) | 18:24 |
| *** zagy has quit IRC | 18:24 | |
| srichter | MJ: I am now sure, but there is a lot of talk about new sprints | 18:25 |
| JoaoJoao | Anyone here knows the current state of the Firebird Z3 DA? | 18:25 |
| srichter | I did not even know we had one | 18:25 |
| srichter | probably not working | 18:25 |
| srichter | but you can easily fix it by looking at working adapters | 18:26 |
| *** zagy has joined #zope3-dev | 18:26 | |
| JoaoJoao | i'll try to make it work, IMHO it's important to have working DAs | 18:27 |
| srichter | of course, but if noone needs a particular DA or even has a particualr database, then there is no need to maintain it | 18:28 |
| srichter | so you are the first one in need of this DA and you are fixing it, which is cool | 18:28 |
| MJ | Bah, 'SiteManager' | 18:30 |
| MJ | Not a good name outside of Zope3.. | 18:30 |
| MJ | What if you have a UML model (a hierarchy) and you want to register new tabs for a sub-tree | 18:31 |
| MJ | I'd have to create a SiteManager for that subtree, but it ain't no site.. | 18:31 |
| whit | how bout LocalManager | 18:32 |
| *** lurker has left #zope3-dev | 18:32 | |
| srichter | it is actually called LocalSiteManager | 18:32 |
| *** J1m has joined #zope3-dev | 18:32 | |
| srichter | and that's what it is | 18:32 |
| srichter | MJ: unfortunately I do not understand your application enough to make suggestions | 18:33 |
| MJ | LocalComponentManager would be more neutral | 18:34 |
| MJ | It is not app specific (which just happens to not be a web-based app) | 18:34 |
| MJ | It is more that the component registration manager's name is web server specific. | 18:34 |
| MJ | Components are useful in other contexts as well. :) | 18:35 |
| *** nie_lunch is now known as niemeyer | 18:35 | |
| *** sashav has quit IRC | 18:39 | |
| *** MacYET has joined #zope3-dev | 18:39 | |
| *** tarek has joined #zope3-dev | 18:39 | |
| *** kbremer has quit IRC | 18:40 | |
| *** MacYET has quit IRC | 18:42 | |
| *** zagy has quit IRC | 18:54 | |
| *** dobee has quit IRC | 19:02 | |
| *** MJ has quit IRC | 19:16 | |
| *** natea is now known as natea|away | 19:23 | |
| *** sashav has joined #zope3-dev | 19:38 | |
| *** vlado has quit IRC | 19:40 | |
| *** andres has quit IRC | 19:40 | |
| *** regebro has quit IRC | 19:42 | |
| *** projekt01 has joined #zope3-dev | 19:43 | |
| *** jinty has quit IRC | 19:54 | |
| *** stub has quit IRC | 20:05 | |
| *** jinty has joined #zope3-dev | 20:08 | |
| *** tarek has quit IRC | 20:11 | |
| *** xenru is now known as xenru|away | 20:13 | |
| *** jinty has quit IRC | 20:19 | |
| *** dhuang has quit IRC | 20:21 | |
| *** mgedmin has joined #zope3-dev | 20:26 | |
| *** tiredbones has joined #zope3-dev | 20:32 | |
| *** srichter has quit IRC | 20:46 | |
| *** dobee has joined #zope3-dev | 20:47 | |
| *** whit has quit IRC | 20:48 | |
| *** efge has quit IRC | 20:48 | |
| *** klaus has joined #zope3-dev | 20:54 | |
| *** klaus has quit IRC | 20:57 | |
| *** Aiste has quit IRC | 21:13 | |
| *** sashav has quit IRC | 21:34 | |
| *** sashav has joined #zope3-dev | 21:36 | |
| *** mkerrin has quit IRC | 21:37 | |
| *** dobee has quit IRC | 21:45 | |
| *** BjornT_ has joined #zope3-dev | 21:57 | |
| *** projekt01 has quit IRC | 22:05 | |
| *** projekt01 has joined #zope3-dev | 22:06 | |
| *** BjornT__ has joined #zope3-dev | 22:08 | |
| *** natea|away is now known as natea | 22:12 | |
| *** BjornT___ has joined #zope3-dev | 22:13 | |
| *** BjornT has quit IRC | 22:15 | |
| *** MJ has joined #zope3-dev | 22:16 | |
| *** BjornT_ has quit IRC | 22:23 | |
| *** yota has quit IRC | 22:24 | |
| JoaoJoao | how do I set the default encoding for Zope3? | 22:30 |
| *** BjornT__ has quit IRC | 22:30 | |
| *** bootsch has joined #zope3-dev | 22:36 | |
| benji | JoaoJoao, not exactly sure what you mean; for input (text boxes, etc.), for source code, for output (html)? | 22:40 |
| *** yota has joined #zope3-dev | 22:41 | |
| *** brupp_ has joined #zope3-dev | 23:07 | |
| JoaoJoao | benji: Oh well it's the DA's fault | 23:07 |
| brupp_ | benji: hi, I'm going through your excellent Zope 3 quick start guide and I have a question | 23:10 |
| brupp_ | Working on todays Zope 3 from SVN, Python 2.4.2. It works all until I get to the point where the forms come into play | 23:10 |
| brupp_ | In particular this line: interface.implements(interfaces.IHelloWorld) | 23:11 |
| benji | brupp_, you've run into a bug I intended to fix this weekend, but didn't have time... | 23:11 |
| brupp_ | Oh, well, then everything is ok. I just thought I was wrong... | 23:11 |
| benji | ...at one time the quick start had a seperate interfaces module, but now they're all in hello | 23:11 |
| *** niemeyer has quit IRC | 23:12 | |
| benji | so, replace "interfaces" with "hello" and you should be good to go | 23:12 |
| brupp_ | Great, thanks. | 23:12 |
| brupp_ | Excellent work, I have to stress that. If every quick guide was like this, then - well - everyone would use Zope ;) | 23:13 |
| benji | Instead of working on the quick start I wrote (most of) a tutorial/manual testing framework so this kind of problem won't happen as much in the future, I hope to finish and have a new version of the quick start out Thursday morning | 23:13 |
| brupp_ | Thanks a lot, I'll check it out for sure | 23:14 |
| benji | thanks for the kind words, I'm hoping to do a larger version soon, we'll see how it turns out | 23:14 |
| brupp_ | Another thing I couldn't really understand with my modest Zope3 knowledge is the ust of the argument "object" in the class definitions instead of "persistent.Persistent". | 23:17 |
| brupp_ | I get this error when trying to start Zope: TypeError: Cache values must be persistent objects. | 23:17 |
| benji | hmm, sounds like a bug, brupp_ | 23:18 |
| benji | all "content" objects should be persistent | 23:18 |
| brupp_ | I just switched back to persistent.Persistent in the hope that I'll figure that out some time in the future ;) | 23:19 |
| benji | I don't understand, the quick start was using "persisten.Persistent", and you substituted "object" and it broke, and you just wondered why. Is that right? | 23:20 |
| brupp_ | Almost, at one point you yourself mention to use "object". Let me search... | 23:21 |
| *** horizon5 has quit IRC | 23:21 | |
| brupp_ | Subtitle ZCML and Templates | 23:21 |
| brupp_ | The first block of code | 23:21 |
| brupp_ | Even above "A New View" | 23:22 |
| benji | that's a bug, I'll fix it (this is why I started writing a test framework :) | 23:22 |
| brupp_ | So what's the correct way, the persistent? | 23:22 |
| benji | yep | 23:22 |
| brupp_ | cool. | 23:22 |
| brupp_ | It's really great to sort this stuff out directly with you, I thought it was some "magic" going on, hehe | 23:23 |
| *** ignas has quit IRC | 23:23 | |
| benji | oh, sorry, I was mistaken, that is a view class, so it needn't be persistent | 23:24 |
| benji | sorry about that | 23:24 |
| benji | do you want to know why? | 23:24 |
| brupp_ | If I understand? :-) | 23:24 |
| brupp_ | I'm not sure if I'm ready, although interested... | 23:24 |
| benji | first, do you know what subclassing object does in python? | 23:25 |
| brupp_ | yes, I think | 23:25 |
| benji | ok, then you understand what it does in Zope 3 :) | 23:25 |
| brupp_ | Hmmm | 23:25 |
| benji | the view class is used to instantiate a view instance every time you view a page | 23:26 |
| brupp_ | Ah, bells ringing | 23:26 |
| benji | the views aren't stored in the database, the content object is (that's why it needs to be persitent) | 23:26 |
| brupp_ | Doesn't have to be persistent in this case | 23:26 |
| benji | right | 23:26 |
| benji | maybe I should reiterate that in the quick start | 23:26 |
| brupp_ | Yeah, that would be great for greenhorns like me ;) | 23:27 |
| benji | cool, I'm making myself a note | 23:27 |
| *** mgedmin has quit IRC | 23:28 | |
| JoaoJoao | Good to know that | 23:29 |
| JoaoJoao | Well the FIrebird DA works now, except when I select a Date or DateTime field | 23:31 |
| *** JoaoJoao has quit IRC | 23:46 | |
| *** xenru|away is now known as xenru | 23:52 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!