| *** _srichter has joined #zope3-dev | 00:00 | |
| *** sashav has quit IRC | 00:05 | |
| *** _strichter has joined #zope3-dev | 00:08 | |
| *** srichter has quit IRC | 00:09 | |
| *** _strichter is now known as srichter | 00:09 | |
| *** ChanServ sets mode: +o srichter | 00:09 | |
| *** _srichter was kicked by srichter (User terminated!) | 00:10 | |
| *** strichter was kicked by srichter (User terminated!) | 00:10 | |
| benji_york | srichter, that'll teach you! | 00:11 |
|---|---|---|
| srichter | LOL :-) | 00:14 |
| srichter | yeah, I had to kick my other zombie selfs out | 00:15 |
| *** sashav has joined #zope3-dev | 00:21 | |
| *** bradb is now known as bradb-away | 00:27 | |
| *** Alef has joined #zope3-dev | 00:28 | |
| *** projekt01 has joined #zope3-dev | 00:30 | |
| J1m | srichter, are you aware that Tim wants advanced warning of z3 releases? | 00:41 |
| srichter | J1m: yes, this is the reason I sent the message today | 00:44 |
| J1m | k | 00:44 |
| srichter | Tim was also part of the discussion that will prompt the new RC | 00:44 |
| srichter | J1m: I think we want DirectResult and StrResult be part of base.py | 00:45 |
| *** Alef has quit IRC | 00:46 | |
| srichter | since the base response currently does not ensure that the passed in result is really a result object | 00:46 |
| J1m | uh | 00:46 |
| J1m | I suppose. | 00:46 |
| J1m | IResult defines headers. | 00:46 |
| J1m | Headers only make sense for HTTP. | 00:47 |
| srichter | mmh, true | 00:47 |
| srichter | maybe it should not | 00:47 |
| srichter | or maybe it should | 00:47 |
| J1m | But, really, the publisher only makes sense for HTTP. :) | 00:47 |
| srichter | ok, I forgot that we are only dealing with HTTP right now | 00:47 |
| srichter | I have a feeling that eventually IResult will not have headers, but there will be an IHTTPResult that does | 00:48 |
| J1m | I have a hope that someday we stop trying to wedge every protocol into the publisher. | 00:48 |
| srichter | I would be even willing to implement this, but I do not see how this can be done for FTP | 00:49 |
| J1m | What "this" are you refering to? | 00:52 |
| srichter | not using the publisher for FTP | 00:52 |
| srichter | in Zope 3, no other protocols are using the publisher | 00:53 |
| J1m | ah | 00:53 |
| J1m | yup | 00:53 |
| J1m | If I was starting over for FTP (and I probably wouldn't bother :), I would have a server-side object that represented the ftp session and had state that included the current position in the object system. | 00:54 |
| J1m | This would obviously be stateful. | 00:54 |
| J1m | In fact, we already do this, but we force this poor beast to go through the publisher for every operation. | 00:54 |
| srichter | right | 00:55 |
| *** bradb-away is now known as bradb | 00:55 | |
| J1m | Note that session object would become the "request". | 00:55 |
| srichter | and who would do the traversal? | 00:56 |
| srichter | a lot of machinery exists in the publisher that deals with finding an object in the path | 00:56 |
| J1m | There would probably be some sort of FTP machine that did the traversal in much the way we do now. | 00:56 |
| J1m | Of coursem the traversal would be stateful. | 00:56 |
| J1m | Actually, not that much. | 00:57 |
| srichter | mmh, keeping the current object around sounds interesting | 00:57 |
| J1m | It could still use the publication model. | 00:57 |
| srichter | this way cd .. is very easy | 00:57 |
| srichter | (to implement) | 00:57 |
| J1m | yes | 00:57 |
| *** GaryPoster has quit IRC | 00:58 | |
| srichter | (I am asking all this since people will want to implement new protocols once twisted is integrated) | 00:58 |
| J1m | authentication remains a tad tricky. | 00:58 |
| srichter | so I want to have a good answer around; maybe FTP could be used as some sort of test case | 00:58 |
| J1m | perhaps | 00:59 |
| *** benji_york has quit IRC | 01:23 | |
| *** jinty has joined #zope3-dev | 01:29 | |
| *** jinty has quit IRC | 01:47 | |
| *** yota has quit IRC | 01:55 | |
| *** stub has joined #zope3-dev | 01:58 | |
| *** J1m has quit IRC | 02:10 | |
| *** bradb has quit IRC | 02:59 | |
| *** bradb has joined #zope3-dev | 03:00 | |
| *** bradb has left #zope3-dev | 03:02 | |
| *** fdrake has left #zope3-dev | 03:15 | |
| *** sashav has joined #zope3-dev | 03:27 | |
| *** sashav has quit IRC | 03:44 | |
| *** tiredbones has joined #zope3-dev | 04:04 | |
| *** GaryPoster has joined #zope3-dev | 04:13 | |
| GaryPoster | stub, ayt? | 04:14 |
| stub | yes | 04:14 |
| GaryPoster | cool. :-) | 04:14 |
| GaryPoster | Um, so trying to explain the i18n problem that may or may not be related to pytz... | 04:15 |
| GaryPoster | Let's see. The most informative mail thread is "Failing test, Zope 3 trunk, Windows" | 04:15 |
| GaryPoster | The proximate cause for the ruckus is that the pytz check in you made on the trunk made a test fail in zope.i18n. When we looked at the test that failed, we all saw that it was a bit insane. | 04:16 |
| GaryPoster | That is, i18n was actually broken both in 3.1 and on the trunk, before your checkin, but we had a broken test hiding it. | 04:17 |
| GaryPoster | Your checkin made the test fail in a new way (sadly, it was still not correct). | 04:18 |
| stub | urg.. EST is a deprecated timezone name. It is probably an alias to US/Eastern | 04:18 |
| GaryPoster | I wondered about that. I thought about changing the test to only use US/Eastern and puking if someone used EST. That has a couple of problems...not least that it still doesn't explain why EST would be 5 hours and 20 minutes off from UTC. | 04:20 |
| GaryPoster | (Which it is now; it used to be 6 hours, which was also wrong) | 04:20 |
| GaryPoster | I looked briefly at the Olson data, and didn't see any reference to 5 hours and 20 minutes; just 5 hours. | 04:21 |
| GaryPoster | I said that puking on EST had another problem--the other problem is that the i18n database apparently still uses EST, so it would be nice if it were sane. | 04:22 |
| GaryPoster | Tim's last email pointed most significantly at pytz for the oddity: see his last email in the "Failing test,..." thread | 04:24 |
| GaryPoster | (I'm about to have to go, btw) | 04:25 |
| stub | Ok... so what is happening is that the EST zone contains two different periods. EST and CST. EST came into existance in 1908. | 04:25 |
| stub | Also, when you construct a datetime in localtime using pytz, you need to use the localize() method as documented in the README | 04:27 |
| GaryPoster | Ah, so the i18n code is using pytz incorrectly? | 04:27 |
| stub | If localize() is called at the relevant points, the correct information for 2003 will be used and everything should be dandy | 04:28 |
| stub | I think that is the issue ;) | 04:28 |
| GaryPoster | Ah ok. Well, that's a lot more than I had to go on before. :-) | 04:28 |
| GaryPoster | OK, I need to run around and do some stuff. Then I'll see if I can fix the i18n stuff (unless you are feeling particularly noble and full-of-vigor-and-free-time :-) ) | 04:29 |
| stub | I was still considering the source api, and if I should accept the arguments or rant ;) | 04:30 |
| GaryPoster | heh, as you see fit :-) | 04:34 |
| *** projekt01 has quit IRC | 04:35 | |
| *** bradb has joined #zope3-dev | 04:42 | |
| stub | GaryPoster: I'll have a look at it actually | 04:45 |
| GaryPoster | Awesome! My wife will thank you for it! :-) | 04:46 |
| stub | Urgh.... more issues. It is creating custom StaticTzInfo instances that I doubt will be picklable with the new code... | 04:48 |
| GaryPoster | That's not a use case we have talked about yet, fwiw: we say "store your dates in UTC, display your dates in what you can guess the user wants, store timezones as generated from pytz.timezones" | 04:52 |
| GaryPoster | pytz.timezone I meant | 04:53 |
| GaryPoster | (But if it is fixable with changes to i18n, so that the dates are picklable, sounds good to me :-) ). BTW, since Stephan is going to do an RC3 of 3.1, we can get the new pytz in 3.1, and ideally also get the improved locale timezones in the i18n locale. | 04:56 |
| *** dman13 has quit IRC | 05:46 | |
| *** dman13 has joined #zope3-dev | 05:49 | |
| *** roym has quit IRC | 06:20 | |
| *** GaryPoster has quit IRC | 06:25 | |
| *** sashav has joined #zope3-dev | 07:44 | |
| *** stu1 has joined #zope3-dev | 07:57 | |
| *** stub has quit IRC | 07:57 | |
| *** sashav has quit IRC | 08:23 | |
| *** stu1 has quit IRC | 09:03 | |
| *** j-w has joined #zope3-dev | 09:06 | |
| *** sashav has joined #zope3-dev | 09:31 | |
| *** yota has joined #zope3-dev | 09:36 | |
| *** tiredbones has quit IRC | 09:36 | |
| *** hdima has joined #zope3-dev | 09:39 | |
| bob2 | so | 09:41 |
| bob2 | are sources ready to replace vocabularies? | 09:41 |
| bob2 | trying to generate a vocabulary for a workflow seems to be harder than I thought | 09:41 |
| *** MJ has quit IRC | 09:45 | |
| *** Alef has joined #zope3-dev | 10:32 | |
| *** jhauser has joined #zope3-dev | 10:44 | |
| *** BjornT has quit IRC | 10:49 | |
| *** stub has joined #zope3-dev | 10:56 | |
| *** MJ has joined #zope3-dev | 11:04 | |
| *** mgedmin has joined #zope3-dev | 11:06 | |
| *** projekt01 has joined #zope3-dev | 11:13 | |
| bob2 | hmm | 11:13 |
| bob2 | is it reasonable to use a view on one object to affect another? | 11:13 |
| mgedmin | maybe | 11:15 |
| mgedmin | if it makes sense from the end-user's point of view | 11:15 |
| mgedmin | and you don't introduce unnecessary dependencies between components | 11:15 |
| bob2 | hm | 11:16 |
| bob2 | I'm sort of conceptually lost | 11:16 |
| bob2 | I have a component, which has a bunch of metadata | 11:16 |
| bob2 | handled through various adapters | 11:16 |
| bob2 | but I'd like to present a view which lets you twiddle them all at once | 11:16 |
| mgedmin | perhaps pagelets/portlets would be a solution? | 11:17 |
| bob2 | hmm | 11:18 |
| bob2 | they don't seem to be mentioned in either of the Books | 11:18 |
| mgedmin | I personally haven't used them yet, BTW, so I might be talking nonsense | 11:18 |
| mgedmin | take a look at zope.app.pagelet | 11:18 |
| bob2 | ah | 11:18 |
| mgedmin | I think that would work fine if your single big page can be modularized (e.g. a bunch of boxes, one for each adapter) | 11:19 |
| mgedmin | otoh if your big page is mix-n-match (this input box here is IFoo(context).foo, the next one is just context.bar, the third one is again IFoo(context).baz) | 11:20 |
| mgedmin | then hardcoding everything in a single view might be the only option | 11:20 |
| *** Alef has quit IRC | 11:23 | |
| bob2 | hmm | 11:24 |
| bob2 | perhaps that's a solution to my "how to have a container view that modifies all the containees" problem, too | 11:24 |
| projekt01 | bob2, it's a base concept to use views in views or even in templates directly | 11:27 |
| projekt01 | bob2, see also the addform concept there is a view called on a view | 11:27 |
| projekt01 | bob2, or the @@absolute_url is a view where is designed to be called in a template | 11:28 |
| *** vlado has joined #zope3-dev | 11:29 | |
| bob2 | hrm | 11:30 |
| projekt01 | bob2, in your case grep for "getMultiAdapter" and you will find views where call other views. | 11:30 |
| bob2 | this is complicated :| | 11:30 |
| mgedmin | is it? | 11:30 |
| mgedmin | render a named view on a subobject in a page template: | 11:30 |
| mgedmin | <div tal:replace="structure some_subobject/@@view_name">...</div> | 11:30 |
| mgedmin | call some helper function of a named view on a subobject in a page template: | 11:31 |
| *** j-w has quit IRC | 11:31 | |
| mgedmin | <span tal:replace="some_subobject/@@view_name/function">...</span> | 11:31 |
| mgedmin | or do that more than once | 11:31 |
| bob2 | hm | 11:31 |
| mgedmin | <div tal:define="helper_view nocall:some_subobject/@@view_name"> | 11:31 |
| mgedmin | <span tal:replace="helper_view/foo">...</span> | 11:31 |
| mgedmin | <span tal:replace="helper_view/bar">...</span> | 11:31 |
| mgedmin | </div> | 11:31 |
| mgedmin | ok, in view code it gets slightly more complicated | 11:32 |
| mgedmin | def some_view_function(self): | 11:32 |
| mgedmin | ... | 11:32 |
| bob2 | this doesn't seem too bad, for displaying things | 11:32 |
| bob2 | handling edits sounds harder | 11:32 |
| projekt01 | bob2, btw, don't be confused about imagine what is a view. Think about a view is just a non persistent python instance where can have views. | 11:32 |
| mgedmin | helper_view = zapi.getMultiAdapter((some_subobject, self_request), name='view_name') | 11:32 |
| mgedmin | helper_view.update_from_form_data() | 11:33 |
| bob2 | hrm | 11:35 |
| mgedmin | actually, if your view expects other views to have some named methods (e.g. to handle form updates) | 11:35 |
| mgedmin | it would be cleander to get views by interface rather than by name | 11:35 |
| mgedmin | zapi.getMultiAdapter((some_subobject, self.request), ISomeKindaView) | 11:35 |
| bob2 | zope3 gets a lot more complicated once you move beyond having single pages editing single objects | 11:36 |
| *** j-w has joined #zope3-dev | 11:37 | |
| mgedmin | well, the problem gets more complicated | 11:37 |
| bob2 | oh, I know | 11:38 |
| projekt01 | mgedmin, you also can use zope.app.pagelet in this case. It's more reusable if needed. | 11:38 |
| SteveA | i know jim would like to make this read simpler with ISomeKindaView(some_subobject, self.request) | 11:38 |
| mgedmin | I'd love to see a nice, simple solution for complex pages editing many objects, in any web framework | 11:38 |
| SteveA | but, it is hard to allow that | 11:38 |
| mgedmin | then I could reimplement it in zope 3 ;) | 11:38 |
| bob2 | SteveA: maybe accept a tuple of both as the first argument? | 11:38 |
| bob2 | I think my real problem is that neither of the Books go into this sort of complicated scenario | 11:39 |
| mgedmin | bob2, here's you chance to write a third book and become famous forever! | 11:40 |
| bob2 | hehe | 11:41 |
| bob2 | is formlib something that could help wit hthis? | 11:49 |
| *** bradb has quit IRC | 12:01 | |
| *** bradb has joined #zope3-dev | 12:01 | |
| *** vlado has quit IRC | 12:22 | |
| *** vlado has joined #zope3-dev | 12:23 | |
| projekt01 | bob2, yes | 12:28 |
| bob2 | it looks interesting | 12:28 |
| bob2 | but running some of the code from form.txt gives me this: | 12:28 |
| bob2 | zope.component.interfaces.ComponentLookupError: ((<zope.schema._bootstrapfields.Int object at 0xb750a14c>, <zope.publisher.browser.TestRequest instance URL=http://127.0.0.1>), <InterfaceClass zope.app.form.interfaces.IDisplayWidget>, u'') | 12:28 |
| *** vlado has quit IRC | 12:35 | |
| mgedmin | running it how? | 12:35 |
| mgedmin | in an interactive Python session? in a unit test? | 12:35 |
| mgedmin | bob2, that error indicates missing component registrations | 12:35 |
| bob2 | by cutting and pasting from it to a python file | 12:35 |
| mgedmin | it should never happen in real life or in a functional test | 12:36 |
| mgedmin | it will always happen otherwise, unless you register widgets yourself | 12:36 |
| bob2 | hm | 12:36 |
| mgedmin | look for provideAdapter calls at the top of form.txt, I guess | 12:36 |
| mgedmin | here's what I do in unit tests, if I want to make sure I can render a page template that contains a form | 12:36 |
| mgedmin | setup.placelessSetUp() | 12:37 |
| mgedmin | setup.setUpTraversal() | 12:37 |
| mgedmin | ztapi.browserView(Interface, 'form_macros', FormMacros) | 12:37 |
| mgedmin | ztapi.browserView(Interface, 'widget_macros', | 12:37 |
| mgedmin | SimpleViewClass('widget_macros.pt', | 12:37 |
| mgedmin | os.path.dirname(zope.app.form.browser.__file__))) | 12:37 |
| mgedmin | ztapi.browserViewProviding(ITextLine, TextWidget, IInputWidget) | 12:37 |
| mgedmin | ... | 12:37 |
| mgedmin | ztapi.browserViewProviding(IInt, IntWidget, IInputWidget) | 12:37 |
| mgedmin | ... | 12:37 |
| mgedmin | ztapi.browserView(IWidgetInputError, '', WidgetInputErrorView, | 12:37 |
| mgedmin | providing=IWidgetInputErrorView) | 12:37 |
| mgedmin | # the actual set of widgets that I register depend on which ones are used in my test/page template | 12:38 |
| mgedmin | # when I get an error, I grep for a corresponding zcml directive in zope.app.form, and then convert it to Python code | 12:39 |
| bob2 | oh, wow | 12:39 |
| bob2 | thanks! | 12:39 |
| mgedmin | I am not entirely convinced rendering page templates in unit tests is a good idea | 12:39 |
| bob2 | I'm trying to get a feel for formlib, more than anything | 12:40 |
| bob2 | before I strap it into the system | 12:40 |
| mgedmin | it helps when your PT contains logic that you want to unit-test, and that would be hard to test in a functional test | 12:40 |
| mgedmin | bob2, in that case it might be simpler to play with zopectl debug -- it will load the zcml for you, I think | 12:40 |
| mgedmin | or just load the site.zcml file yoursel at the top of your python script | 12:40 |
| bob2 | is this similar to using Debugger? | 12:41 |
| mgedmin | maybe -- I haven't used either much | 12:41 |
| *** sashav has quit IRC | 12:53 | |
| *** bob2 has quit IRC | 12:53 | |
| *** Hellfried has quit IRC | 12:53 | |
| *** sashav has joined #zope3-dev | 12:53 | |
| *** bob2 has joined #zope3-dev | 12:53 | |
| *** Hellfried has joined #zope3-dev | 12:53 | |
| bob2 | hm, where does FormMacros come from? | 12:58 |
| mgedmin | use the tags, luke | 13:01 |
| *** ignas has joined #zope3-dev | 13:09 | |
| *** stub has quit IRC | 13:20 | |
| *** stub has joined #zope3-dev | 13:21 | |
| *** BjornT has joined #zope3-dev | 13:31 | |
| bob2 | now I'm down to: | 13:37 |
| bob2 | zope.component.interfaces.ComponentLookupError: ((<zope.schema._bootstrapfields.Int object at 0xb7371bac>, <zope.publisher.browser.TestRequest instance URL=http://127.0.0.1>), <InterfaceClass zope.app.form.interfaces.IDisplayWidget>, u'') | 13:37 |
| mgedmin | so you didn't use the quick suggestion of loading the real zcml file? | 13:40 |
| * mgedmin shrugs | 13:40 | |
| mgedmin | ztapi.browserView(IInt, IntDisplayWidgetOrSomething, IDisplayWidget) | 13:40 |
| mgedmin | you'll have to figure out the name of the Int display widget class yourself | 13:40 |
| bob2 | oh, I wasn't sure how to load the real zcml file | 13:41 |
| bob2 | oops | 13:41 |
| mgedmin | isn't that like xmlconfig('filename')? | 13:41 |
| mgedmin | I'd look for a .zcml file somewhere in a tests/ subdir, then grep for it in test_*.py | 13:41 |
| *** vlado has joined #zope3-dev | 13:54 | |
| mgedmin | bob2, one way to do it: | 13:55 |
| mgedmin | from zope.configuration.xmlconfig import XMLConfig | 13:55 |
| mgedmin | XMLConfig('filename.zcml')() | 13:55 |
| mgedmin | I guess you want | 13:56 |
| mgedmin | import zope.app | 13:56 |
| mgedmin | XMLConfig('configure.zcml', zope.app)() | 13:56 |
| *** ignas has quit IRC | 13:57 | |
| bob2 | hm, thanks a lot (again) | 14:08 |
| bob2 | if you're ever in .au, remind me to buy you a beer :) | 14:08 |
| * mgedmin doesn't drink beer, but would accept a cup of tea ;) | 14:09 | |
| *** alga has joined #zope3-dev | 14:14 | |
| *** stub has quit IRC | 14:16 | |
| *** mgedmin has quit IRC | 14:17 | |
| *** efge has joined #zope3-dev | 14:17 | |
| *** ignas has joined #zope3-dev | 14:20 | |
| *** anguenot has joined #zope3-dev | 14:26 | |
| *** projekt01 has quit IRC | 14:26 | |
| *** projekt01 has joined #zope3-dev | 14:27 | |
| *** regebro has joined #zope3-dev | 14:44 | |
| *** regebro has quit IRC | 14:52 | |
| bob2 | hm | 14:59 |
| *** roym has joined #zope3-dev | 14:59 | |
| roym | sorry to be asking the same thing over and over again - but how would I get the roles for a given principal? | 15:00 |
| srichter | look at the permission maps of all objects in your object path | 15:01 |
| *** faassen has joined #zope3-dev | 15:01 | |
| projekt01 | roym, grep for the method getRolesForPrincipal and use principal_id not principal as the argument for the principal | 15:02 |
| *** vlado has quit IRC | 15:06 | |
| *** tiredbones has joined #zope3-dev | 15:27 | |
| *** MrTopf has joined #zope3-dev | 15:30 | |
| *** GaryPoster has joined #zope3-dev | 15:37 | |
| bob2 | hm | 15:38 |
| bob2 | when using formlib, __call__ on an instance of the class produces the output | 15:38 |
| bob2 | how do I call that using TAL? | 15:38 |
| *** regebro has joined #zope3-dev | 15:39 | |
| roym | projekt01: thanks for answering... | 15:39 |
| projekt01 | np | 15:39 |
| bob2 | (normally I'd call a method on the instance) | 15:40 |
| projekt01 | bob2, tal:define="myCalledView python:view()" if the view is already a instance | 15:42 |
| bob2 | hrm | 15:45 |
| bob2 | I don't think I can make an instance statically | 15:45 |
| bob2 | since __init__ takes request and context | 15:46 |
| SteveA | have you tried tal:replace="structure yourinstance" ? | 15:47 |
| SteveA | if that does not work, yourinstance/__call__ is ugly but ought to work | 15:47 |
| * SteveA wonders about using a trailing / to indicate calling vs not calling behaviour in TALES | 15:48 | |
| *** benji_york has joined #zope3-dev | 15:48 | |
| bob2 | I can't quite see where yourinstance would be instantiated, tho | 15:49 |
| projekt01 | Hm, I'm not sure if I got you right, if you call a view from a ZPT like: myObjectOrContext/@@myView you get the adapted view instance where you should able to call. | 15:49 |
| bob2 | ah | 15:49 |
| *** Alef has joined #zope3-dev | 15:50 | |
| projekt01 | bob2, tal:define="yourinstance context/@@MyView" | 15:50 |
| projekt01 | See also the breadcrumb concept e.g. context/@@absolute_url/breadcrumbs | 15:51 |
| *** alga has quit IRC | 15:56 | |
| *** d2m has quit IRC | 15:57 | |
| *** J1m has joined #zope3-dev | 16:03 | |
| bob2 | hrm | 16:13 |
| bob2 | this is rapidble spiraling out of comprehension | 16:36 |
| GaryPoster | bob2: you are using formlib. What's the problem exactly? | 16:36 |
| *** stub has joined #zope3-dev | 16:36 | |
| bob2 | GaryPoster: I'm not sure of the correct TAL and ZCML code to make use of a form.Form derivative, it seems | 16:37 |
| GaryPoster | OK. The zcml is most simply a browser:page directive. It does some extra muck that you don't want, but it takes care of the security quickly and easily. | 16:38 |
| bob2 | right, I have that | 16:39 |
| GaryPoster | Otherwise you can use a standard adapter element and configure the security as you need. | 16:39 |
| GaryPoster | So what is the TAL problem? | 16:39 |
| bob2 | (I'm just using the same sort of :page declaration I did with a BrowserView subclass) | 16:39 |
| GaryPoster | Sure, should be fine | 16:39 |
| bob2 | ComponentLookupError: (<test.page.TestForm object at 0xb3f79a8c>, <InterfaceClass zope.formlib.namedtemplate.INamedTemplate>, 'default') | 16:41 |
| bob2 | hmm | 16:42 |
| GaryPoster | So that means that you have not registered a NamedTemplate for the TestForm class or its interface. If you are subclassing form.Form, that makes sense: the default templates are for the derivatives (edit and so on) | 16:43 |
| bob2 | because I didn't setup the template correctly, I guess | 16:43 |
| bob2 | perhaps a stupid question, but what's a NamedTemplate? | 16:43 |
| GaryPoster | :-) Not stupid. | 16:43 |
| GaryPoster | It's also in formlib. You can either ignore it, and slam a template attribute on your class that's an actual page template, or | 16:44 |
| GaryPoster | read about them in the namedtemplate.txt file in formlib | 16:45 |
| bob2 | ah, thank you :) | 16:47 |
| GaryPoster | np :-) | 16:47 |
| bob2 | right now my :page declaration points at a template, which then has TAL which calls the form.Form object | 16:47 |
| bob2 | NamedTemplate lets you invert that and have the formlib object insert itself into a template? | 16:47 |
| GaryPoster | Ah. No, the page declaration should point to the formlib object as the class. Don't specify a template. | 16:48 |
| GaryPoster | Yes | 16:48 |
| GaryPoster | Although I wouldn't put it that way... :-) | 16:48 |
| GaryPoster | But that's beside the point so I'm not going to get into it (if that's ok) | 16:49 |
| bob2 | heh, np :) | 16:51 |
| bob2 | does | 16:55 |
| bob2 | <page | 16:55 |
| bob2 | for="test.page.IThing" | 16:55 |
| bob2 | name="test.html" | 16:55 |
| bob2 | permission="zope.View" | 16:55 |
| bob2 | class="test.page.TestForm" | 16:55 |
| bob2 | /> | 16:56 |
| bob2 | look reasonable if test.page.TestForm is a subclass of form.Form? | 16:56 |
| *** vlado has joined #zope3-dev | 17:00 | |
| srichter | J1m: I just found a serious bug in our WSGI support | 17:02 |
| srichter | J1m: can I pick your brain a bit? | 17:02 |
| srichter | in the WSGI support we get the response from the request before we publish it | 17:03 |
| srichter | we do this because request.close() sets the response on the request to None | 17:04 |
| srichter | however, when a request is retried a completely new instance of the request is created in Request.retry() | 17:05 |
| srichter | this means that the response we originally saved is not the one that is used after the retry | 17:06 |
| srichter | here are a couple solutions: | 17:06 |
| srichter | * retry does not create a new instance, but simply cleans itself carefully | 17:07 |
| srichter | * publish returns the response object | 17:07 |
| srichter | I think the latter fits better our new model | 17:08 |
| srichter | thoughts? | 17:08 |
| srichter | benji_york: GaryPoster: is Jim around? | 17:08 |
| GaryPoster | srichter: in meeting | 17:08 |
| benji_york | he's in a meeting right now | 17:08 |
| *** hdima has quit IRC | 17:09 | |
| GaryPoster | bob2: yes, looks ok | 17:09 |
| bob2 | GaryPoster: thanks a lot | 17:09 |
| srichter | GaryPoster: any idea when that will be over? | 17:09 |
| GaryPoster | srichter: none, sorry | 17:10 |
| *** projekt01 has quit IRC | 17:10 | |
| *** sashav has quit IRC | 17:16 | |
| *** yota has quit IRC | 17:22 | |
| *** tiredbones has quit IRC | 17:22 | |
| *** __gotcha has quit IRC | 17:22 | |
| *** genconc has quit IRC | 17:22 | |
| *** SteveA has quit IRC | 17:22 | |
| *** vlado has quit IRC | 17:22 | |
| *** J1m has quit IRC | 17:22 | |
| *** MrTopf has quit IRC | 17:22 | |
| *** ignas has quit IRC | 17:22 | |
| *** lucia12345 has quit IRC | 17:22 | |
| *** VladDrac has quit IRC | 17:22 | |
| *** tav has quit IRC | 17:22 | |
| *** Jim7J1AJH has quit IRC | 17:22 | |
| *** Alef has quit IRC | 17:22 | |
| *** GaryPoster has quit IRC | 17:22 | |
| *** faassen has quit IRC | 17:22 | |
| *** anguenot has quit IRC | 17:22 | |
| *** MJ has quit IRC | 17:22 | |
| *** dman13 has quit IRC | 17:22 | |
| *** srichter has quit IRC | 17:22 | |
| *** tvon has quit IRC | 17:22 | |
| *** deo has quit IRC | 17:22 | |
| *** andrew_m has quit IRC | 17:22 | |
| *** jack-e has quit IRC | 17:22 | |
| *** FarcePest has quit IRC | 17:22 | |
| *** regebro has quit IRC | 17:23 | |
| *** roym has quit IRC | 17:23 | |
| *** efge has quit IRC | 17:23 | |
| *** BjornT has quit IRC | 17:23 | |
| *** Hellfried has quit IRC | 17:23 | |
| *** bob2 has quit IRC | 17:23 | |
| *** benji_york has quit IRC | 17:23 | |
| *** peaceman has quit IRC | 17:23 | |
| *** bradb has quit IRC | 17:23 | |
| *** j-w has quit IRC | 17:23 | |
| *** jhauser has quit IRC | 17:23 | |
| *** vinsci has quit IRC | 17:23 | |
| *** philiKON has quit IRC | 17:23 | |
| *** Theuni has quit IRC | 17:23 | |
| *** Aiste has quit IRC | 17:23 | |
| *** regebro has joined #zope3-dev | 17:26 | |
| *** roym has joined #zope3-dev | 17:26 | |
| *** efge has joined #zope3-dev | 17:26 | |
| *** BjornT has joined #zope3-dev | 17:26 | |
| *** bob2 has joined #zope3-dev | 17:26 | |
| *** Hellfried has joined #zope3-dev | 17:26 | |
| *** srichter has joined #zope3-dev | 17:27 | |
| *** genconc has joined #zope3-dev | 17:27 | |
| *** __gotcha has joined #zope3-dev | 17:27 | |
| *** segoave has joined #zope3-dev | 17:27 | |
| *** SteveA has joined #zope3-dev | 17:27 | |
| *** andrew_m has joined #zope3-dev | 17:27 | |
| *** FarcePest has joined #zope3-dev | 17:27 | |
| *** jack-e has joined #zope3-dev | 17:27 | |
| *** deo has joined #zope3-dev | 17:27 | |
| *** tvon has joined #zope3-dev | 17:27 | |
| *** dman13 has joined #zope3-dev | 17:27 | |
| *** MJ has joined #zope3-dev | 17:27 | |
| *** anguenot has joined #zope3-dev | 17:27 | |
| *** faassen has joined #zope3-dev | 17:27 | |
| *** GaryPoster has joined #zope3-dev | 17:27 | |
| *** Alef has joined #zope3-dev | 17:27 | |
| *** yota has joined #zope3-dev | 17:27 | |
| *** Jim7J1AJH has joined #zope3-dev | 17:27 | |
| *** lucia12345 has joined #zope3-dev | 17:27 | |
| *** VladDrac has joined #zope3-dev | 17:27 | |
| *** ignas has joined #zope3-dev | 17:27 | |
| *** MrTopf has joined #zope3-dev | 17:27 | |
| *** J1m has joined #zope3-dev | 17:27 | |
| *** vlado has joined #zope3-dev | 17:27 | |
| *** fdrake has joined #zope3-dev | 17:27 | |
| *** tav has joined #zope3-dev | 17:27 | |
| *** irc.freenode.net sets mode: +oo srichter tav | 17:27 | |
| *** peaceman has joined #zope3-dev | 17:27 | |
| *** jhauser has joined #zope3-dev | 17:27 | |
| *** bradb has joined #zope3-dev | 17:27 | |
| *** vinsci has joined #zope3-dev | 17:27 | |
| *** philiKON has joined #zope3-dev | 17:27 | |
| *** Aiste has joined #zope3-dev | 17:27 | |
| *** tiredbones has joined #zope3-dev | 17:27 | |
| *** Theuni has joined #zope3-dev | 17:27 | |
| *** Jim7J1AJH has quit IRC | 17:28 | |
| *** yota has quit IRC | 17:28 | |
| *** yota has joined #zope3-dev | 17:30 | |
| *** benji_york has joined #zope3-dev | 17:31 | |
| *** j-w has joined #zope3-dev | 17:31 | |
| ignas | hi | 17:33 |
| srichter | hi | 17:33 |
| ignas | a question - if i have two <a> tags in py template that have only one difference one of tham has no "href" attribute in it's tal:attributes | 17:34 |
| *** peaceman has joined #zope3-dev | 17:34 | |
| ignas | is ther a way to do it without <tal:if contition="foo"><a attrs="href foo; class some_class"></tal:if><tal:if contition="not:foo"><a attrs="class some_class"></tal:if> | 17:35 |
| bob2 | shouldn't you be provindg the attribute, empty? | 17:35 |
| ignas | like <a tal:attrbutes="href: empty; class some_class"> ? | 17:36 |
| fdrake | only provide <a href="..."> if you want it to be a link source | 17:36 |
| ignas | fdrake, ? | 17:37 |
| fdrake | link source == clickable to follow the link | 17:37 |
| fdrake | so you need the conditional | 17:37 |
| ignas | :( | 17:38 |
| fdrake | yeah | 17:38 |
| fdrake | but lemme check something | 17:38 |
| fdrake | ugh; can't get to (www|dev).zope.org | 17:39 |
| *** BjornT has quit IRC | 17:40 | |
| *** tvon has quit IRC | 17:41 | |
| fdrake | ah; you should be able to use tal:attributes="href nothing" | 17:41 |
| fdrake | if you're using a Python expression, you can use None for nothing | 17:42 |
| *** Jim7J1AJH has joined #zope3-dev | 17:43 | |
| ignas | oh, i see | 17:43 |
| ignas | thanks | 17:43 |
| J1m | srichter, pong | 17:43 |
| srichter | J1m: did you get my explanation above? | 17:44 |
| J1m | yes | 17:44 |
| J1m | I agree that we need to refactor this a bit. | 17:44 |
| srichter | ok | 17:44 |
| J1m | This is related to our discussions about "application boundary". | 17:44 |
| srichter | yep | 17:44 |
| J1m | I think we need to revisit what request.close does. | 17:45 |
| srichter | actually I miswrote | 17:45 |
| srichter | its not even a request.close() issue | 17:45 |
| J1m | I see no reason why it has to lose the response. | 17:45 |
| *** BjornT has joined #zope3-dev | 17:45 | |
| srichter | the issue is really that the publish() function can create new requests | 17:45 |
| J1m | lemme look ... | 17:46 |
| srichter | when a retry occurs a new request is created | 17:46 |
| J1m | ok | 17:46 |
| srichter | publish.py line 157 | 17:46 |
| J1m | I agree that, in the new world, publish should return the request with the response intact. | 17:47 |
| J1m | wrt reset, it *is* being used, not *not* for retry. | 17:47 |
| srichter | ok | 17:47 |
| J1m | It is used for error handling. | 17:47 |
| srichter | yeah, I saw this after I wrote the message | 17:48 |
| J1m | wrt reset, it *is* being used, but *not* for retry. | 17:48 |
| J1m | :) | 17:48 |
| srichter | on the other hand, it seems strange to me that the publisher can create a new request | 17:49 |
| srichter | especially since you pass one in | 17:49 |
| J1m | I also think we need to think a bit more about the response API. | 17:49 |
| *** Jim7J1AJH has quit IRC | 17:50 | |
| J1m | well, the publisher is creating a new logical request. | 17:50 |
| J1m | I could live with a strategy of reusing the request. | 17:50 |
| srichter | yes, but we pass a logical request to the publisher | 17:50 |
| J1m | Yes, and it creates a new one. | 17:50 |
| J1m | I'm OK with either approach. | 17:50 |
| srichter | right, I think people would not expect this | 17:50 |
| srichter | mmh, I wish you would have a stronger opinion :-) | 17:51 |
| J1m | sorry :) | 17:51 |
| srichter | changing retry to using reset might be the quickest solution, but might cause unwanted side effects | 17:52 |
| J1m | wrt the response, I'm not too happy that client (esp test code) gets response.result.body. | 17:52 |
| srichter | right, I agree that this seems unclean | 17:52 |
| J1m | I'm inclined to suggest that the response should be private, but I'm not really sure. | 17:52 |
| srichter | wow, that would be a big change | 17:53 |
| J1m | srichter, again I don't have a strong aopinion about retry vs reset. | 17:53 |
| J1m | I'm not sure it would be a big change. | 17:53 |
| J1m | I'm also not sure it would be a desireable change. :) | 17:53 |
| srichter | because a lot of code uses response.*Header* and response.redirect() | 17:53 |
| srichter | I personally don't mind response to be public | 17:54 |
| J1m | Huh? | 17:54 |
| J1m | Not response, response.result. | 17:54 |
| J1m | response should be public. | 17:54 |
| faassen | phew. :) | 17:54 |
| * faassen was about to rip all response.redirect() from his codebase. :) | 17:54 | |
| srichter | ok, you had a typo above then | 17:54 |
| J1m | I was suggesting that the result (response.result) might not be public. | 17:54 |
| srichter | I think this might be a good idea | 17:55 |
| J1m | oh, sorry | 17:55 |
| *** Jim7J1AJH has joined #zope3-dev | 17:55 | |
| srichter | so we would need to expose the body access in the response somehow | 17:55 |
| J1m | yes | 17:56 |
| srichter | and then this would be for the HTTP requests too | 17:56 |
| J1m | something like: | 17:56 |
| J1m | response.iterbody() | 17:56 |
| J1m | response.body() | 17:56 |
| J1m | the later gets a string | 17:56 |
| J1m | Note that "bodies" are HTTP specific. | 17:56 |
| srichter | will the latter return the headers as well? | 17:56 |
| srichter | good point | 17:57 |
| J1m | This gets back to the discussion we had yesterday. | 17:57 |
| srichter | which aspect? | 17:57 |
| J1m | It might be much cleaner if the publisher was only about HTTP. | 17:57 |
| srichter | that we should rip out the FTP support? | 17:57 |
| srichter | right | 17:57 |
| J1m | Or provide the FTP support with a more FTP-oriented publisher. | 17:57 |
| srichter | right, that's what I meant | 17:58 |
| J1m | CGI isn't a good model for FTP. :) | 17:58 |
| srichter | :-) | 17:58 |
| J1m | But, of course, traversal, paths, etc. are relevent to both. | 17:58 |
| J1m | I would expect many concepts and possibly frameworks (e.g. publication) to be shared. | 17:59 |
| srichter | yes, so I wonder whether the concept of publications could be reused | 17:59 |
| srichter | :-) | 17:59 |
| J1m | anyway, I wouldn't suggest doing this for 3.2. | 17:59 |
| J1m | We are running out of time. | 17:59 |
| srichter | yep, right now I just want to get all tests fixed on the branch | 18:00 |
| J1m | I'd like to get what we started at the sprint, along, of course, with the twisted work, wrapped up in time for 3.2. | 18:00 |
| srichter | so that we can implement the BB correctly and switch to the new code | 18:00 |
| J1m | yup | 18:00 |
| srichter | I think it will be about a day of work once all tests are passing | 18:01 |
| srichter | (there are only two left, both of which will be fixed by fixing the discussed issue) | 18:01 |
| srichter | ok, here is the simplest solution: | 18:01 |
| J1m | I also think that someone will want to leverage this and ZODB blobs to make the large file story better. | 18:01 |
| srichter | have publish() return request, response | 18:02 |
| srichter | this will be least intrusive | 18:02 |
| SteveA | i was having a discussion with marius over lunch, about some issues with the default Zope security policy. it expects __parent__ attributes, but does not demand that the objects provide an interface that says "IHaveAParentAttribute". We discussed why an interface is not demanded. The answer seems to be that this would be too much of an imposition on application developers, to make almost every object provide this interface. Unfortunately, this leaves | 18:02 |
| SteveA | an implicit dependency on __parent__. | 18:02 |
| J1m | have it return request. | 18:02 |
| J1m | have request retain the response attr. | 18:02 |
| *** Alef has quit IRC | 18:02 | |
| srichter | J1m: ok | 18:03 |
| *** ignas has quit IRC | 18:03 | |
| SteveA | (implicit dependencies on attributes are *so* zope2) | 18:03 |
| J1m | SteveA, we don't check the interface for performance reasons. | 18:03 |
| J1m | It's a tradeoff. | 18:03 |
| SteveA | not even when in debug mode. not even when running tests. | 18:03 |
| * srichter always dreamed of making a change in the publish() function; seems very important! :-) | 18:03 | |
| J1m | The vast majority of objects that have __parent__ provide ILocation. | 18:04 |
| J1m | SteveA, I'm +1 on adding an interface check in devel/debug mode. | 18:04 |
| SteveA | cool | 18:04 |
| J1m | Then, of course, we need to be prepared to run tests *both* in debug and non-debug mode, at least on the buildbot. | 18:05 |
| SteveA | or... | 18:05 |
| J1m | BTW, I wonder if we bother to pass -O to python when running in production mode. | 18:05 |
| SteveA | make the code that runs in debug mode try both checking the interface and looking for the attribute. | 18:05 |
| SteveA | if the results differ, that's an error | 18:05 |
| J1m | Probably not, since we don't really have explicit devel and production modes. | 18:06 |
| J1m | yes | 18:06 |
| SteveA | iow, it is an error to provide __parent__ without providing ILocation | 18:06 |
| srichter | J1m: see my devmode proposal | 18:06 |
| SteveA | that statement makes me queasy | 18:06 |
| J1m | srichter, k | 18:06 |
| SteveA | an interface should not put requirements on things that don't provide it | 18:06 |
| J1m | SteveA, I'm not so sure about that. | 18:06 |
| SteveA | seems to me to be a consequence of the optimisation of not checking the interface | 18:07 |
| J1m | But an object should be free to have an attribute that it doesn't promise to provide. | 18:07 |
| SteveA | yes, of course | 18:07 |
| * SteveA needs to get back to debuging some authentication / virtual host issues | 18:08 | |
| J1m | BTW, we will be releasing a security policy that makes much less use of __parent__. | 18:09 |
| J1m | This policy is much simpler than the default Z3 policy. | 18:09 |
| J1m | It also provides an example of what's rquired to write an alternative policy. | 18:10 |
| SteveA | hurrah. i use one that makes no use of __parent__, btw. but then, my objects aren't arranged in a hierarchy like in many zodb applications. | 18:10 |
| SteveA | i'm pretty sure i can release mine at some point soon. | 18:11 |
| J1m | cool | 18:11 |
| srichter | J1m: all tests are passing now | 18:26 |
| *** MrTopf has quit IRC | 18:34 | |
| *** alga has joined #zope3-dev | 18:39 | |
| J1m | Great | 18:39 |
| *** tvon has joined #zope3-dev | 18:40 | |
| *** vlado has quit IRC | 18:44 | |
| srichter | J1m: btw, we also need to write the mail to the WSGI group | 18:49 |
| srichter | we need an answer (at least preliminary) for Zope 3.2 | 18:49 |
| *** mgedmin has joined #zope3-dev | 18:50 | |
| srichter | J1m: do you want me to implement body and iterbody for HTTP requests? | 19:04 |
| *** vlado has joined #zope3-dev | 19:13 | |
| *** ignas has joined #zope3-dev | 19:14 | |
| *** j-w has quit IRC | 19:25 | |
| J1m | srichter, I assume that the email you are refering to is wrt auth user | 19:29 |
| srichter | yes | 19:30 |
| srichter | J1m: because currently the zserver does not log the auth user, which it did before | 19:30 |
| J1m | Yup, I think we should send that email. | 19:31 |
| J1m | wrt body and iterBody, I think that would be good, if you agree, | 19:32 |
| srichter | yeah, I think this sounds fine, though only one can be called once | 19:32 |
| srichter | also, should body return the headers as well? I guess not | 19:32 |
| J1m | Really, they both can be called only once. | 19:32 |
| J1m | no | 19:33 |
| srichter | right | 19:33 |
| GaryPoster | srichter: I have an APIdoc bug I'd like to chat with you about. Do you want me to chat with you at the same time as Jim, or can you ping me when you are available? Ideally we'd chat within the next half hour, but if that's not possible that's ok | 19:34 |
| srichter | wrt the auth user, should be make a specific suggestion, like: We need an additional wsgi env variable called XXX | 19:34 |
| srichter | or do we just want to raise the issue | 19:34 |
| J1m | yes | 19:34 |
| J1m | I think we should make a specific proposal. | 19:34 |
| srichter | ok | 19:34 |
| srichter | GaryPoster: contact me privately | 19:35 |
| GaryPoster | OK will do | 19:35 |
| srichter | J1m: do you think that it will suffice to add a new env var called "wsgi.authuser" or should we address logging more generally | 19:35 |
| srichter | i.e. env['wsgi.loginfo'] = {} | 19:36 |
| srichter | and then define the keys that can be in this dictionary | 19:36 |
| *** Aiste has quit IRC | 19:37 | |
| J1m | I *think* that authuser is the only field the app is responsible for. | 19:42 |
| J1m | I would stay specific. | 19:42 |
| J1m | Maybe "wsgi.commonlog.authuser", but whatever you think is best. | 19:42 |
| srichter | ok, sounds good | 19:51 |
| srichter | adding the commonlog namespace makes sense | 19:51 |
| *** BjornT_ has joined #zope3-dev | 19:54 | |
| *** BjornT_ has quit IRC | 19:56 | |
| *** yota has quit IRC | 20:11 | |
| *** BjornT has quit IRC | 20:11 | |
| *** bradb has quit IRC | 20:11 | |
| *** fdrake has quit IRC | 20:11 | |
| *** J1m has quit IRC | 20:11 | |
| *** lucia12345 has quit IRC | 20:11 | |
| *** genconc has quit IRC | 20:11 | |
| *** VladDrac has quit IRC | 20:11 | |
| *** __gotcha has quit IRC | 20:11 | |
| *** tav has quit IRC | 20:11 | |
| *** vlado has quit IRC | 20:11 | |
| *** mgedmin has quit IRC | 20:11 | |
| *** tvon has quit IRC | 20:11 | |
| *** alga has quit IRC | 20:11 | |
| *** Theuni has quit IRC | 20:11 | |
| *** segoave has quit IRC | 20:11 | |
| *** GaryPoster has quit IRC | 20:11 | |
| *** andrew_m has quit IRC | 20:11 | |
| *** dman13 has quit IRC | 20:11 | |
| *** faassen has quit IRC | 20:11 | |
| *** MJ has quit IRC | 20:11 | |
| *** anguenot has quit IRC | 20:11 | |
| *** FarcePest has quit IRC | 20:11 | |
| *** srichter has quit IRC | 20:11 | |
| *** jack-e has quit IRC | 20:11 | |
| *** SteveA has quit IRC | 20:11 | |
| *** deo has quit IRC | 20:11 | |
| *** genconc has joined #zope3-dev | 20:11 | |
| *** alga has joined #zope3-dev | 20:11 | |
| *** mgedmin has joined #zope3-dev | 20:11 | |
| *** VladDrac has joined #zope3-dev | 20:11 | |
| *** BjornT has joined #zope3-dev | 20:11 | |
| *** vlado has joined #zope3-dev | 20:11 | |
| *** segoave has joined #zope3-dev | 20:11 | |
| *** andrew_m has joined #zope3-dev | 20:11 | |
| *** faassen has joined #zope3-dev | 20:11 | |
| *** tav has joined #zope3-dev | 20:11 | |
| *** anguenot has joined #zope3-dev | 20:11 | |
| *** bradb has joined #zope3-dev | 20:12 | |
| *** srichter has joined #zope3-dev | 20:12 | |
| *** fdrake has joined #zope3-dev | 20:12 | |
| *** J1m has joined #zope3-dev | 20:12 | |
| *** Theuni has joined #zope3-dev | 20:12 | |
| *** MJ has joined #zope3-dev | 20:12 | |
| *** __gotcha__ has joined #zope3-dev | 20:12 | |
| *** lucia12345 has joined #zope3-dev | 20:12 | |
| *** ChanServ sets mode: +o srichter | 20:12 | |
| *** __gotcha__ is now known as __gotcha | 20:12 | |
| *** GaryPoster has joined #zope3-dev | 20:12 | |
| *** FarcePest has joined #zope3-dev | 20:12 | |
| *** SteveA has joined #zope3-dev | 20:12 | |
| *** tvon has joined #zope3-dev | 20:12 | |
| *** Aiste has joined #zope3-dev | 20:13 | |
| *** yota has joined #zope3-dev | 20:17 | |
| srichter | J1m: do you want body and iterbody to be attributes of functions? (I am for the former) | 20:31 |
| J1m | I am for the later. | 20:37 |
| J1m | :) | 20:37 |
| J1m | Perhaps: getBody and iterBody. | 20:37 |
| J1m | They are unlike attributes because you can call them only once. | 20:37 |
| srichter | ok, good point | 20:38 |
| faassen | if you can call them only once, you might want to use 'useBody'? | 20:43 |
| faassen | if I understand it correctly. | 20:43 |
| srichter | it is more a retrieval | 20:44 |
| srichter | I guess that name would work too | 20:44 |
| faassen | i | 20:44 |
| faassen | use sort of implies it's used up. :) | 20:44 |
| faassen | I've been using it in a few places. | 20:44 |
| srichter | true | 20:45 |
| srichter | someone can change this later | 20:45 |
| srichter | I really want to get done wioth the branch | 20:45 |
| J1m | +1 on use. | 20:45 |
| J1m | This is an important semantic. | 20:45 |
| J1m | (or consumeBody) | 20:46 |
| J1m | (consumeBodyIter :) | 20:46 |
| SteveA | how deliciously zombie | 20:46 |
| srichter | J1m: btw, how can a BaseResponse get to its result once result is private? | 20:46 |
| J1m | Night of the living read? | 20:46 |
| faassen | consume is also nice. :) | 20:47 |
| benji_york | consumeBrains.... consumeBrains..... | 20:47 |
| *** xenru has joined #zope3-dev | 20:47 | |
| srichter | we have tests that get the result from a BaseResponse isntance | 20:47 |
| J1m | srichter, it could be protected (single _) | 20:47 |
| srichter | ok, so I just use response._result in the tests? | 20:48 |
| J1m | srichter, you can keep "result" in the implementation and not include it in the interface -- if you don't want to change the tests. | 20:48 |
| faassen | see you all. | 20:50 |
| *** faassen has quit IRC | 20:50 | |
| srichter | J1m: I am already changing the tests ;-) | 20:50 |
| *** bob2 has quit IRC | 20:51 | |
| *** bob2 has joined #zope3-dev | 20:51 | |
| *** efge has quit IRC | 20:53 | |
| *** projekt01 has joined #zope3-dev | 21:01 | |
| *** projekt01 has joined #zope3-dev | 21:01 | |
| srichter | J1m: so what name do we want to use? | 21:01 |
| srichter | consumeBosy and consumeBodyIter? | 21:02 |
| J1m | Martijn should pick. ;) | 21:02 |
| J1m | \These sound fine (with obvioud corrections :) to me. | 21:02 |
| J1m | ugh | 21:02 |
| srichter | ok | 21:02 |
| *** philiKON has quit IRC | 21:06 | |
| *** douglasc has joined #zope3-dev | 21:09 | |
| projekt01 | GaryPoster and benji_york, are you there? | 21:20 |
| benji_york | yep | 21:20 |
| GaryPoster | yes | 21:21 |
| projekt01 | Did you take a look at the pagelets? | 21:21 |
| projekt01 | Doesn't this fit the requirements for additional CSS/JS rendering | 21:22 |
| GaryPoster | No. :-( Jim mentioned we needed to look at that today. Does the resourcelibrary stuff overlap? | 21:22 |
| srichter | I think the pagelet code needs a simpler example | 21:23 |
| srichter | like a simplest possible case | 21:23 |
| projekt01 | It's exactly what you describe in the mail | 21:23 |
| *** anguenot has quit IRC | 21:23 | |
| projekt01 | Yup, a simple example whould help, | 21:23 |
| projekt01 | Just a small abstratct... | 21:24 |
| projekt01 | ... it isn't that easy to describe shortly. | 21:26 |
| projekt01 | What kind of sample would be useful? | 21:26 |
| GaryPoster | Darn. OK, we'll look at that ASAP. We thought it was more like little pages, rather than being useful for JS and CSS. | 21:26 |
| GaryPoster | Example:...thinking | 21:26 |
| srichter | Example is easy | 21:27 |
| srichter | I have some code that wants to insert a CSS file above, when used | 21:27 |
| srichter | exactely the widget use case | 21:27 |
| GaryPoster | OK, good. :-) Hard to ask for an example for something you don't know. :-) | 21:27 |
| projekt01 | Yes, something like little pages where can be registred on "context-, view- and slot - interfaces". | 21:27 |
| srichter | J1m: I am done with the branch; it is ready to be merged | 21:28 |
| GaryPoster | He's away from the computer | 21:28 |
| projekt01 | btw, the zope.app.boston skin makes havy use of fill javascript and CSS slots with pagelets. | 21:28 |
| GaryPoster | (I'm his IM bot, apparently ;-) ) | 21:28 |
| GaryPoster | ok | 21:28 |
| GaryPoster | I'm looking at the pagelet readme | 21:30 |
| *** vlado has quit IRC | 21:30 | |
| projekt01 | GaryPoster, pagelets are also like dynamic fill-slot component, where the slot is the key for get dynamicly the registred pagelet (little views) | 21:30 |
| *** vlado has joined #zope3-dev | 21:31 | |
| projekt01 | a pagelet get rendered together with the page template at once and not before you include them. | 21:32 |
| GaryPoster | I wonder if it could use something like the resourcelibrary as a client--the pagelet stuff starts out with a model that I guess you have to follow. The resourcelibrary doesn't require much of a model--it's just a simple API. Talking with Jim... | 21:33 |
| projekt01 | if you use a python class for register a pagelet (like in the page directive), you have the scope of context and view in this pagelet class | 21:33 |
| srichter | GaryPoster: I am not particularly in favor of resource library | 21:33 |
| srichter | in my books it is a hack :-) | 21:34 |
| srichter | if you want piping you should do it the right way using XSLT | 21:34 |
| projekt01 | You only need to define a interface for the pagelet slot and call this in the page templage like pagelet:path.to.interface | 21:34 |
| projekt01 | then you can register <pagelet slot="path.to.interface" ...> there is nothing more needed. | 21:35 |
| projekt01 | but the same concept can be used for allmost everything else. | 21:36 |
| projekt01 | I like this, that pagelets can solve so many problems with just one concept. | 21:36 |
| srichter | GaryPoster: btw, you probably want to look at zope.app.demo.pagelet | 21:36 |
| projekt01 | GaryPoster, I'm not really sure if I get the use case of register JS libraries right. Are you mean the include of <script langauge="javascript" src="..." /> | 21:38 |
| projekt01 | or register nested folders of large javascript libraries as resources? | 21:38 |
| GaryPoster | srichter, projekt01: back. | 21:38 |
| J1m | srichter, wrt the branch: Yay! | 21:39 |
| srichter | J1m: are we ready to merge? | 21:39 |
| srichter | or do we need to do more? | 21:39 |
| *** sashav has joined #zope3-dev | 21:39 | |
| J1m | srichter, I'd like to chat with you using a higher-bandwidth medium. :) | 21:40 |
| * J1m wonders if dialog is working in srichter's irc client. | 21:41 | |
| srichter | need my phone number? | 21:41 |
| GaryPoster | srichter, yes, already acknowledged that current implementation is not ideal; the idea is to expose the API, which means we can have other implementations. XSLT Is fine, but not required to do what we need. In the absence of an XSLT processor, we did something simple and effective. Jim is talking about a pipeline between the request and the response: that sounds like it would work great for what we want. | 21:41 |
| J1m | Yes, feel free to dialog me if you don't want to share it with the world. | 21:41 |
| *** MJ has quit IRC | 21:43 | |
| GaryPoster | projekt01: yes, I need to look up some examples. What you describe sounds a lot simpler than the start of the pagelet README looks. :-) It also really doesn't look like what we are doing. We are not including parts of a page, we are including javascript libraries: pdlib, prototype, etc. The resourcelibrary does both of what you list. | 21:46 |
| projekt01 | GaryPoster, do I get it right, that you don't have to declare something in the ZPT, this happens hidden and appends the right tags in the page header? | 21:48 |
| GaryPoster | yep. | 21:49 |
| * mgedmin wonders if there's a zodb tool for opening a read-only Data.fs, and copying the most recent records of all objects into a new Data.fs -- IOW nondestructive packing of a live data.fs | 21:49 | |
| projekt01 | Ok, then I like your concept and think that' much better then using pagelets for this. | 21:50 |
| projekt01 | GaryPoster, can we enhance and use this concept for inject other parts as javascript and CSS tags? | 21:51 |
| srichter | mgedmin: copy, pack? | 21:53 |
| benji_york | projekt01, what do you have in mind? | 21:54 |
| srichter | benji_york: projekt01: oh, we are going down this slippery road of inventing our own pipelining technology | 21:54 |
| GaryPoster | projekt01: Cool! But I've already been assigned the task of grokking pagelets, I think, so I'll get into them more. :-) | 21:55 |
| *** Alef has joined #zope3-dev | 21:55 | |
| projekt01 | benji_york, nothing special, just see find out the limit of inject something without to define it in ZPT. | 21:56 |
| srichter | J1m: task.write is non-blocking | 21:56 |
| srichter | though it puts everything in an output buffer, so probably it takes up the memory | 21:57 |
| srichter | J1m: actually, I think it does the right thing | 21:58 |
| srichter | it uses zope.server.buffers.OverflowableBuffer, which seems to create a temp file, when output is large | 21:59 |
| GaryPoster | We can inject anything in theory; but I agree with Stephan (at least in part) that what we are doing here is a hack, waiting for a real pipeline hook. I don't agree that a real pipeline hook (or two, since Jim is talking about both WSGI pipeline and a pipeline between request and response) must be XSLT to not be a hack. I want the hook we've forced in with resourcelibrary to be as constrained in scope as possible. | 22:01 |
| *** vlado_ has joined #zope3-dev | 22:02 | |
| benji_york | projekt01, also you don't *have* to trigger the insertion via ZPT, you can also programmatically trigger the inclusion | 22:04 |
| projekt01 | benji_york, that's cool, but in general I'm not this happy with pipelines. I can't imagine that graphic people can handle this part and I don't like to do their job in the future too. | 22:06 |
| projekt01 | but perhaps it's easier then I can think about right now ;-) | 22:07 |
| benji_york | projekt01, I'm afraid I don't understand, but no matter :) | 22:07 |
| *** Alef has quit IRC | 22:08 | |
| projekt01 | benji_york, I like to outsource the ZPT work to graphic peoples in the future and I have some fear that this would be not understandable with XSLT pipelines. | 22:09 |
| benji_york | ok | 22:09 |
| J1m | mgedmin, you can do that now using a symbolic link. | 22:10 |
| J1m | Make a symbolic link, open it read only and pack it. | 22:10 |
| J1m | (Test this to be sure, but I'm 94% sure this works.) | 22:11 |
| J1m | wrt pipelines: | 22:11 |
| J1m | - I agree that they don't have to be xslt. For example, the xslt-based Cocoon uses lots of non-xslt pipeline segments. | 22:12 |
| J1m | - I think that pipelines are not the only model that can be used here. If transformations are independent, they could be performed by subscribers, rather than in a pipeline. | 22:13 |
| projekt01 | btw, I like the idea to have a kind of pipeline for the javascript and CCS injection part in the header area of a page. | 22:13 |
| J1m | Of course, a pipeline could be used even where ordering isn't necessary. | 22:13 |
| J1m | But, I suspect that avoiding oprdering when it's not necessary will make things more pluggable. | 22:14 |
| projekt01 | J1m, javascript tags must follow a ordered if you write it object oriented and split they in libraries. | 22:14 |
| GaryPoster | But if there is a single subscriber for the resourcelibrary, it can handle the ordering. | 22:15 |
| J1m | exactly | 22:15 |
| projekt01 | what does it mean a single subscriber? | 22:16 |
| J1m | The idea is that the resource library accumulates needed JS and CSS dirubf the request. | 22:17 |
| J1m | At the end, it then inserts this accumulated material into the page. | 22:17 |
| J1m | s/dirubf/during | 22:18 |
| J1m | :) | 22:18 |
| J1m | This last step can be done by a single subscriber. | 22:18 |
| srichter | will the hook be sensible to content types? | 22:19 |
| *** MJ has joined #zope3-dev | 22:19 | |
| srichter | i.e. we do not want to inspect an image | 22:19 |
| projekt01 | Does this mean we can register such JS/CSS combination as libraries. But the javascript files can be located in different packages? | 22:20 |
| * J1m really needs to read the cocoon book again | 22:20 | |
| *** vlado has quit IRC | 22:20 | |
| J1m | I'm most interested in using pipelines for post-processing results of calling published objects. | 22:22 |
| projekt01 | J1m, can you describe a use case? | 22:22 |
| J1m | Of course, pipelines can be puplished directly (e.g. used to implement views). | 22:22 |
| J1m | Sure. I can describe a couple (probably several if I put my mind to it. :) | 22:23 |
| projekt01 | ;-) | 22:23 |
| J1m | 1. Add needed JS and CSS resources to a page after it is rendered. | 22:23 |
| J1m | 2. Add a standard look and feel. (aka "o wrap") to a page. | 22:24 |
| *** segoave has left #zope3-dev | 22:24 | |
| J1m | I don't think page macros have worked very well for controlling look and feel. | 22:25 |
| J1m | I'd like to remove the responsibility from a view designer for producing standard look and feel. | 22:25 |
| projekt01 | I agree, the (1.) should be implemented for 3.2. It's a feature we really need. Other things are nice to have in the future. | 22:27 |
| *** douglasc has quit IRC | 22:30 | |
| projekt01 | J1m, Yes, views contains to much layout relevant tags right now. btw, I really like to cleanup and replace some tags in views which makes it hard to apply different layouts. | 22:30 |
| * J1m GaryPoster and benji_york discuss pipelines ... :) | 22:41 | |
| projekt01 | J1m, btw, is there a relevant roadmap for zope3? | 22:42 |
| *** alga has quit IRC | 22:43 | |
| *** mgedmin has quit IRC | 22:47 | |
| jhauser | as a supplement to pipelines was there ever a discussion about an application context for views? | 23:02 |
| jhauser | I mean an application which controls the o-wrap | 23:03 |
| *** dman13 has joined #zope3-dev | 23:03 | |
| srichter | J1m: merge complete | 23:04 |
| J1m | projekt01, no roadmap for z3. | 23:07 |
| J1m | IMO, roadmaps are less important when: 1. we have time-based releases, and 2. we have little control over what people will work on. | 23:07 |
| *** jinty has joined #zope3-dev | 23:07 | |
| J1m | Still, some sort of planning document would be nice, where people could at least note what they want or are working on. | 23:08 |
| J1m | jhauser, I don't know what you mean. | 23:08 |
| srichter | J1m: would you prefer that I merge the twisted stuff in as soon as it works, but before we finish all other deisred tasks? | 23:09 |
| J1m | The new rule is: don't merge unless you think it's releasable. | 23:09 |
| jhauser | I mean that the descisions, what would appear on a page beside the main content is controlled by an application | 23:09 |
| J1m | jhauser, which application? | 23:09 |
| srichter | J1m: it will be releasable but not contain all goodies we are planning | 23:10 |
| fdrake | srichter: GMail truncated your merge message ;-) | 23:10 |
| J1m | srichter, then yes. | 23:10 |
| srichter | :-( | 23:10 |
| srichter | J1m: ok, I try to get this done in the next weeks then | 23:10 |
| jhauser | generally it would mainly be a place were different components can register themself | 23:10 |
| jhauser | the view of the content would register itself for the main part of the application | 23:11 |
| jhauser | perhaps I understand pipelines not enough, but they mainly transform, what's already there | 23:12 |
| jhauser | for example a portalpage has many bits which have a high overall application logic | 23:13 |
| jhauser | "show the loginbox if not logged in, else show the userinfo, taken from somewhere" | 23:13 |
| jhauser | to do this in a pipeline, the parts of the pipeline need to go back to something to ask, should I show the login box" | 23:14 |
| jhauser | they need to reach back so to speak | 23:15 |
| *** xenru has quit IRC | 23:16 | |
| J1m | jhauser, right. | 23:16 |
| J1m | The idea is to do composition at the presentation layer in some sort of loose way. | 23:17 |
| J1m | I'm not sure I understand pipelines well either. | 23:17 |
| J1m | In any case, I think it would be fairly non-controversial to use a pipeline (or pipeline-like thing) to post process something returned by calling objects. | 23:18 |
| J1m | But pipeline advocates would also advocate pipelines for implementing the orginal view. | 23:18 |
| jhauser | right, my understanding up to now is that the get all the information they need and are fairly self sustained | 23:19 |
| J1m | A very simple case that I think has merit is to separate information production from page production. | 23:19 |
| J1m | This is the ClearSilver approach that I think could be done as well with ZPT. | 23:20 |
| jhauser | ok, that I understand | 23:20 |
| jhauser | but that leaves the logic in the information production step | 23:20 |
| jhauser | mainly to decide what information is displayed | 23:21 |
| J1m | Yes | 23:21 |
| jhauser | and this is also part of the o-wrap | 23:21 |
| J1m | Of course, the XML/XSLT zealots would implement *that* as a pipeline too. :) | 23:21 |
| J1m | well, yes and no, depending on what you consider the o-wrap to be. | 23:22 |
| J1m | In Cocoon, the o-wrap is implemented as an XSLT template that effectively invokes pipelines (if I remember correctly). | 23:23 |
| jhauser | these pipelines are data centric | 23:23 |
| jhauser | they mangle data packed in xml | 23:24 |
| J1m | too bad Paul and Martijn aren't here | 23:24 |
| jhauser | this does not solve the question where should responsibilities be placed | 23:24 |
| projekt01 | jhauser, pagelets are a concept where you can assemble such selective "little views" to one page. But the each page template has to define define its slots explicit. | 23:24 |
| jhauser | and this is undestood as a hinderence to easy customization, right? | 23:26 |
| jhauser | layout customization I mean | 23:26 |
| projekt01 | jhauser, I don't understand what do you mean with layout? | 23:29 |
| jhauser | if the slots need to be defined in a pagetemplate is becomes more complicated, and as such it becomes harder to simply change the layout. | 23:30 |
| jhauser | harder for a non programmer | 23:31 |
| projekt01 | Pagelets are used for add additional content to a existing pagelets dependent on registration via ZCML (this means you can render content where is not defined in the ZPT explicit) | 23:32 |
| jhauser | I'm not against or for something, I only want to see clearer what get's solved with the various proposed approaches | 23:32 |
| jhauser | so the ZPT defines places where parts can be placed with ZCML | 23:33 |
| projekt01 | jhauser, Pagelets can not solve layout problems ;-( | 23:33 |
| projekt01 | Yes, exactly | 23:34 |
| jhauser | are you using them in tiks? | 23:34 |
| projekt01 | I use most the time a layout pagelet which is called as a pagelet from the data pagelet. | 23:35 |
| projekt01 | Yes, extensive | 23:35 |
| projekt01 | The boston skin in zope.app.boston uses also pagelets | 23:35 |
| jhauser | ah ok | 23:36 |
| projekt01 | But, I would be happy to see a good concept for the layout part. This isn't the scope of pagelets. | 23:37 |
| projekt01 | Perhaps I have to think about that again and take a look at the pipeline stuff too. Would be nice if we could use one concept for wrap layout and inject content at once. | 23:38 |
| projekt01 | But I like to implement the MVC patter 2.0 first before other things. I really run again and again into problems to control my object instance because of the MVC 1.5 pattern where we use in z3. | 23:42 |
| jhauser | yes it would be good to have one general concept | 23:42 |
| jhauser | MVC has versions ? | 23:42 |
| projekt01 | Hope to show a concept where we really be able to control a instance and all its menus, views etc | 23:42 |
| projekt01 | Yes, but the are just two concepts 1.5 (used in z3) and 2.0 where has a additional controller for a model | 23:43 |
| projekt01 | the MVC 1.5 has views on a context but no controller where controls the access fro views. | 23:44 |
| jhauser | we have tried to use something like an appcontrol behind the view | 23:45 |
| jhauser | that's the application I meant before | 23:45 |
| jhauser | a general controller for the page | 23:45 |
| projekt01 | Are you comming to the sprint? | 23:45 |
| jhauser | but it's rather hard to keep this thing simple and non redundant | 23:45 |
| jhauser | in köthen? | 23:46 |
| projekt01 | I mean a controller for the model which is the object instance e.g. context | 23:47 |
| projekt01 | No, Neckar | 23:47 |
| jhauser | ah no not planed | 23:47 |
| jhauser | it's in the beginning of october, right | 23:47 |
| projekt01 | yes, October 6-9, 2005 | 23:48 |
| projekt01 | jhauser, what was your target for develop a controller? | 23:49 |
| jhauser | we wanted the view methods to be simple, provide only the data, which is central to the page | 23:50 |
| jhauser | and we didn't want that the pagetemplate reaches back to get navigation, rightboxes and so on | 23:50 |
| jhauser | so the object view places itself in the in something like the mainview, which is just a datastructure provided by the application context | 23:51 |
| projekt01 | Imagine a controller on a context where provides a API. Right now this is implemented in the view class. | 23:52 |
| jhauser | right, we have relativ simple view classes | 23:52 |
| projekt01 | A controller could split the data and view part for use in simply views. | 23:52 |
| jhauser | but the appcontroller does not know which object it publishes | 23:53 |
| jhauser | or not really | 23:53 |
| jhauser | we change controllers for special parts of a page | 23:53 |
| projekt01 | A controller could provide a API for all widgets and a different API on the controller could serve the data for the widgets. | 23:54 |
| jhauser | for example a discussion forum woul get it's own controller | 23:54 |
| jhauser | do you think of an API like boxprovider | 23:55 |
| projekt01 | I mean the controller could be a adapter for the context where you can call IController(yourForum) | 23:55 |
| projekt01 | what do you mean with a boxprovider? | 23:55 |
| jhauser | the controller collects objects, which are already in the presentation stage | 23:56 |
| jhauser | so you can call a box and put things into it, then the box is placed in slots of the controller | 23:56 |
| jhauser | I mean this kind of API | 23:57 |
| projekt01 | That does the pagelet concept right now. | 23:57 |
| projekt01 | The controller is only a API on the context where can be used if you need to get information from a object. | 23:58 |
| jhauser | na it's better if I try to sketch this down and provide it before your sprint, as third party example | 23:58 |
| jhauser | our stuff is far from clean, although it grew from general idea | 23:59 |
| *** vlado_ has quit IRC | 23:59 | |
| projekt01 | e.g. a controller is the API used in the view, This means a controller will adapt your context/object and enhance the object with methods where the object doesn't provide | 23:59 |
| projekt01 | Ok, would be cool to see different ideas | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!