IRC log of #zope3-dev for Thursday, 2006-05-25

*** niemeyer has quit IRC00:10
*** philiKON has quit IRC00:13
*** philiKON has joined #zope3-dev00:13
*** dobee has quit IRC00:21
*** gumpa-away has quit IRC00:40
*** mgedmin has quit IRC00:42
*** jinty has quit IRC00:44
*** fcorrea has left #zope3-dev00:51
*** niemeyer has joined #zope3-dev00:57
*** tonico has quit IRC00:58
*** dunny has quit IRC01:04
*** GaryPoster has quit IRC01:08
*** philiKON has quit IRC01:09
*** zbir has quit IRC01:14
*** russf has quit IRC01:15
*** philiKON has joined #zope3-dev01:18
*** natea has quit IRC01:29
*** projekt01 has joined #zope3-dev01:29
*** dunny has joined #zope3-dev01:58
*** yutakashino has joined #zope3-dev02:10
*** RaFromBRC|away is now known as RaFromBRC02:22
*** roman_ has quit IRC02:47
*** retsu__ has joined #zope3-dev03:14
*** rocky is now known as rocky|Zzz03:19
*** yutakashino has quit IRC03:40
*** yota has quit IRC03:56
*** jinty has joined #zope3-dev04:44
*** yutakashino has joined #zope3-dev05:30
*** jinty has quit IRC05:36
*** projekt01 has left #zope3-dev05:37
*** RaFromBRC has quit IRC06:07
*** rykomats has joined #zope3-dev06:21
*** benji has quit IRC06:36
*** povbot` has joined #zope3-dev07:12
*** povbot has quit IRC07:12
*** SteveA has quit IRC07:13
*** SteveA has joined #zope3-dev07:27
*** niemeyer has quit IRC07:39
*** retsu__ has quit IRC07:58
*** natea has quit IRC08:05
*** retsu__ has joined #zope3-dev08:06
*** natea has joined #zope3-dev08:06
*** febb has quit IRC08:30
*** RaFromBRC has joined #zope3-dev08:34
*** rykomats has quit IRC08:34
*** dobee has joined #zope3-dev08:35
*** philiKON has quit IRC08:44
*** SureshV has joined #zope3-dev08:51
*** eins has joined #zope3-dev08:52
*** dobee has quit IRC08:54
*** rocky|Zzz has quit IRC08:59
*** dobee has joined #zope3-dev09:31
*** hdima has joined #zope3-dev09:32
*** RaFromBRC has quit IRC09:40
*** russf has joined #zope3-dev09:42
*** retsu___ has joined #zope3-dev10:03
*** rykomats has joined #zope3-dev10:03
*** retsu__ has quit IRC10:09
*** tanghus has joined #zope3-dev10:13
*** jukart has joined #zope3-dev10:15
*** russf has quit IRC10:24
*** russf has joined #zope3-dev10:37
*** russf has quit IRC10:42
*** volvox has joined #zope3-dev12:02
*** romanofski has joined #zope3-dev12:18
*** vlado has joined #zope3-dev12:25
*** mkerrin has joined #zope3-dev12:29
*** Aiste has quit IRC12:39
*** rocky has joined #zope3-dev12:40
romanofskihmpf... seems that the boston skin is missing from the zope 3.2 tarball on ?!12:45
d2mromanofski: true, and iirc the svn export of the skin wont work with the distribution12:47
romanofskioh.. alright12:47
* romanofski checks again the 3.2 branch out12:48
*** dlk has joined #zope3-dev12:54
*** Aiste has joined #zope3-dev13:01
*** Pupeno has left #zope3-dev13:05
*** rock1 has joined #zope3-dev13:08
*** mgedmin has joined #zope3-dev13:08
*** rocky has quit IRC13:08
*** rock1 is now known as rocky13:08
*** J1m_ has joined #zope3-dev13:09
rockygood morning13:10
*** rock1 has joined #zope3-dev13:16
*** rocky has quit IRC13:20
*** rock1 is now known as rocky13:20
*** J1m_ has quit IRC13:26
*** jinty has joined #zope3-dev13:35
*** alga has joined #zope3-dev13:38
*** retsu___ has quit IRC13:49
*** dunny has quit IRC13:56
*** ignas has joined #zope3-dev14:04
*** nathany has joined #zope3-dev14:17
*** zbir has joined #zope3-dev14:25
*** yutakashino has quit IRC14:35
*** zagy has joined #zope3-dev14:39
*** yota has joined #zope3-dev15:15
*** philiKON has joined #zope3-dev15:31
*** J1m has quit IRC15:40
*** projekt01 has joined #zope3-dev15:46
*** alga has quit IRC15:46
*** GaryPoster has joined #zope3-dev16:21
*** jinty has quit IRC16:24
*** benji has joined #zope3-dev16:25
*** projekt01 has quit IRC16:27
*** jinty has joined #zope3-dev16:29
*** nathany_ has joined #zope3-dev16:30
*** nathany has quit IRC16:30
*** niemeyer has joined #zope3-dev16:31
*** nathany_ has quit IRC16:46
*** nathany_ has joined #zope3-dev16:47
*** jinty has quit IRC16:54
*** projekt01 has joined #zope3-dev16:59
projekt01GaryPoster, ayt?17:05
GaryPosterHey, yes17:05
projekt01do you know how the formlib get_rendered should work?17:05
GaryPosternot off-hand.  lemme look.17:06
projekt01This method is only working if setUpWidget is used.17:06
*** alecm|away is now known as alecm17:06
projekt01It doesn' work with setUpInputWidget. I guess it's also useful with input forms.17:07
projekt01or at least with AddForm's.17:07
GaryPosterSo, one thing is that AIUI we eventually want to remove the non-setUpWidgets versions, because I think setUpWidgets can do the job of all of them17:08
GaryPosterI agree that it is a bug for the non-setUpWidgets to not have the get_rendered behavior17:09
projekt01ok, perhaps we can add a setRenderedValue method in the form which is invoked if using get_rendered methods?17:09
projekt01I guess if we use get_rendered this method should allways override also the field.default.17:10
projekt01or not?17:10
GaryPosterThe behavior in setUpWidgets is the desired behavior, and it seems that it should be portable to the other setUp*Widgets versions17:11
GaryPosterSo my fix would be to change the setUp*Widgets to do the same thing.17:11
GaryPosterDoes that make sense?17:12
projekt01I guess if we use get_rendered, this method should allways the only one method which can set a value.17:12
GaryPosterIn the default behavior, yes, I think that is right17:12
GaryPoster(it is form*lib* :-) )17:13
*** efrerich has joined #zope3-dev17:13
projekt01Should we change this after the feature freeze?17:14
GaryPosterI think this is a bug: form fields offer the behavior in their API, but the behavior is only implemented if you use one of the possible form base classes.  I'd argue it is a broken promise.17:15
projekt01Hm, right, and I have a usecase for this. I guess this means that I should change it ;-)17:16
GaryPoster:-) sounds good to me17:16
projekt01Do you think we should merge up the setUpWidget part now?17:17
GaryPosterI think that's too big of a change for this stage in the release process.17:20
GaryPosterI can ask Jim's opinion if you want, though17:20
projekt01I guess not right now because I don't have to much time to write tests.17:21
projekt01but I'll fix the usage of the get_render function now. Ok?17:22
GaryPosterwell, arguably you would remove tests at most: tests should already exist for the base classes, which you would change to use setUpWidgets.  If there are isolated tests for the setUp*Widgets, you'd remove them.17:23
GaryPosterBut yes, just fixing get_render is fine by me17:23
projekt01Ok, can you agree, if we use a get_render method this should be the only one which will  set the value?17:24
projekt01Ok, I will fix this.17:24
projekt01thanks a lot17:24
GaryPosternp thank you17:25
projekt01GaryPoster, which exception should I raise if get_rendered is set and readonly is True?17:29
GaryPosterHm.  This is when you are constructing the FormField?17:30
GaryPosterI don't think you need to raise an error17:31
GaryPosterlook at setUpWidgets again--17:31
projekt01Yup, it's a result of a wrong form/field/interface construct. Probably a FormError?17:32
GaryPosterit uses get_rendered if ((we are ignoring the request, or it is readonly, or the widget doesn't have input) and form name is not in the data, and get_rendered is defined)17:33
GaryPostertherefore it is acceptable to set readonly to True and define a get_rendered17:33
projekt01This should change to something like:17:35
projekt01        if form_field.get_rendered is not None:17:35
projekt01            if readonly:17:35
projekt01                raise interfaces.FormError(...)17:35
projekt01        elif ignore_request or readonly or not widget.hasInput():17:35
projekt01or not?17:35
*** gumpa has joined #zope3-dev17:35
projekt01This would make the get_rendered the *master* function and let ignore others if used.17:35
projekt01Hm, this would mean that the get_rendered allways has to handle the form input.17:36
GaryPosterAh, ok, so you want to change the behavior of setUpWidgets, and that is what you meant when you asked me "if we use a get_render method this should be the only one which will  set the value?"17:37
GaryPosterNo, I disagree then17:37
GaryPosterWe need the behavior as is found in setUpWidgets.  setUpWidgets should not need to be touched.17:37
GaryPosterFor instance, in setUpInputWidgets17:38
GaryPosterWhere now it is17:38
projekt01Ok, I agree, this means we should use:17:38
projekt01        if form_field.get_rendered is not None and ignore_request:17:38
projekt01            if readonly:17:38
projekt01                raise interfaces.FormError(...)17:38
projekt01        elif ignore_request or readonly or not widget.hasInput():17:38
GaryPoster        if ignore_request:17:39
GaryPoster            value = field.default17:39
GaryPoster            widget.setRenderedValue(value)17:39
*** jinty has joined #zope3-dev17:39
GaryPoster        if ignore_request:17:39
GaryPoster            if form_filed.get_rendered is not None:value = field.default17:39
GaryPoster            widget.setRenderedValue(value)17:39
GaryPosterignore that last one, I'll do it in an editor and paste it in17:40
*** SureshV has quit IRC17:41
GaryPoster        if ignore_request:17:41
GaryPoster            if form_field.get_rendered is not None:17:41
GaryPoster                value = form_field.get_rendered(form)17:41
GaryPoster            else:17:41
GaryPoster                value = field.default17:41
GaryPoster            widget.setRenderedValue(value)17:41
projekt01Yes, that's correct for the setUpInputWidget.17:41
GaryPosterSo what are you changing in your code snippet? :-)17:42
projekt01But the setUpWidget follows other rules for get_rendered usage.17:42
projekt01Does it really make sense if we use get_rendered  and ignore this method in some usecase?17:42
projekt01I guess if we use get_rendered, this is the method where is used in setRenderedValue.17:43
projekt01I any usecase. otherwise it's confusing because of it's dependency on other parts.17:44
GaryPosterLet me say that back to you to see if I understand17:44
GaryPosterIf get_rendered is defined, and something else doesn't override it (as defined in the logic in the setUpWidgets code), it should provide the value for setRenderedValue17:45
GaryPosterNot all of the cases in setUpWidgets are pertinent to all of the setUp*Widgets, so the logic can be simpler in the other versions (e.g., the code I pasted)17:46
projekt01what do you mean by something else override it?17:46
GaryPosterJust as I said before--use get_rendered if ((we are ignoring the request, or it is readonly, or the widget doesn't have input) and form name is not in the data, and get_rendered is defined)17:47
projekt01I guess get_rendered should in any usecase do:17:47
projekt01otherwise we can't use the get_rendered method for override from.request values.17:48
projekt01The question is, should get_rendered do this?17:48
projekt01I think if get_rendered is responisbel for set the value in any case it's easier to understand what's going on.17:49
GaryPosterAh!  You want to override request values!  You *want* to change the behavior in setUpWidgets!17:49
projekt01No just that the get_rendered method is allways used. Which is the same if a request is given.17:50
projekt01This means we need a default get_rendered which does handle the form.request values like now17:50
projekt01So if no get_rendered is given we get the same behavior17:51
projekt01But if a get_rendered method is used it will always be invoked.17:51
GaryPosterNo, that's too big of a change, IMO.17:52
GaryPosterYou want to do this on an individual field basis, so ignore_request is not good enough for you?17:52
projekt01Ok, I agree, I didn't think of that at the beginning, but right now I think it's the correct behaviour.17:53
projekt01It doesn't make sense to me that get_rendered sometimes is ignored.17:53
projekt01I guess we have to think about that and perhaps write a proposal.17:54
GaryPosterIf anything, perhaps it is a naming problem17:54
GaryPosterget_initial_rendered_value would be more apt17:55
GaryPosterif significantly more ugly17:55
projekt01Yup, that is the behavior right now. But a post "setRenderedValue" concept is also missing?17:56
GaryPosterWell, that's changing what the user has typed/chosen, that really what you want?17:57
projekt01It whould let a developer to invoke a method for e.g. value conversion etc.17:58
GaryPosterConcrete example, maybe?17:58
projekt01I need to set a value for a field if no value is given.17:58
projekt01But not the default.17:59
*** hdima has quit IRC17:59
projekt01This value comes form another instance17:59
GaryPosterset a value on the object, or in the form?17:59
projekt01In the add or edit form.17:59
projekt01Just provide a default value which is not defined in the interface.18:00
projekt01This value comes from e.g. local utility18:00
projekt01The main function is; if a edit form get reseted, the value from the utility schould be used in the edit form.18:02
*** sawdog has joined #zope3-dev18:02
*** rykomats has quit IRC18:04
GaryPosterAnd you don't want that value shown when the form is first drawn?18:05
projekt01In the add form (initial) should the value get used from the utility for the new instance.18:06
projekt01This could be done by what we discussed before18:06
projekt01But the edit form should show the (default value stored in the utility) if I reset the form.18:07
GaryPosterWhat does "reset the form" mean in that context?18:10
projekt01If I changed the values in the edit form and stored some "wrong" settings,18:10
projekt01I can reset to some initial given values stored from the administrator in a utility18:11
projekt01Let's say you have a complex input describing complex stuff and you changed this but it dodn't work.18:12
projekt01Now you can get the initial working value back with " a kind of reset" form.18:13
*** mexiKON has joined #zope3-dev18:14
projekt01I guess I will implement this part in the update method of my form.18:15
projekt01Perhaps we can later think about a method like setRenderedValue() in fromlib18:17
GaryPoster(Sorry doing other things) Yes, that's what I would suggest.  Maybe a proposal for the formlib change.  I think I understand the use case, at least, although I would want to reset to the current values, not abstract values, which formlib allows18:17
projekt01I have other usecases but they are to complex. Like a tree widget which I have to post process before I get a usefull value.18:18
projekt01Ok, I will think about this part later.18:19
GaryPosterthat again seems to be either the responsiblity of the form or of the widget.  I do a lot of post-processing of form values, within the form code (i.e., no change to formlib needed)18:20
projekt01Yes, that's correct but why not register such post process methods per widget rather then override the update method and doing it there?18:21
*** philiKON has quit IRC18:21
projekt01The confusing part is the rendered_get method which suggest to do this for you.18:22
GaryPosteragreed, I think that is a problematic name, stemming from the18:22
GaryPostereh, cross out the last three words ;-)18:22
projekt01Ok, I think we should not change the formlib right now before we think again about this.18:24
GaryPosterOK, though I still agree that setUpInputWidgets et al should honor get_rendered the same way setUpWidgets does18:25
projekt01As a kind of initial_get_rendered concept?18:26
GaryPosterright.  So that the forms honor the interface of formfields18:27
projekt01Ok, I can try to fix that.18:31
*** eins has quit IRC18:36
*** vlado has quit IRC18:37
*** stub has quit IRC18:49
projekt01GaryPoster, can I change this:19:05
projekt01def setUpInputWidgets(form_fields, form_prefix, context, request,19:05
projekt01                      ignore_request=False):19:05
projekt01def setUpInputWidgets(form_fields, form_prefix, context, request,19:05
projekt01                      form=None, ignore_request=False):19:05
GaryPosterOh, interesting19:05
projekt01or should I define form=None inside the setUpWidget?19:06
GaryPosterNo, we need the from to do this19:06
GaryPostersorry from -- form19:08
GaryPosterI guess that change is reasonable19:08
projekt01Ok I will run the tests and commit the changes, can double check it later?19:09
*** volvox has quit IRC19:09
projekt01GaryPoster, it's in the trunk, let me know if I can merge it to the branch 3.319:17
GaryPosterk, will do.  will try to ping you in an hour or so19:17
projekt01Ok, I'm back later tonight, you can merge it or send me a mail if I'm not online.19:19
GaryPosterok, will do.  thanks19:19
projekt01thanks to you19:19
*** oferw has joined #zope3-dev19:56
*** oferw has quit IRC20:20
*** admp has joined #zope3-dev20:40
*** jinty has quit IRC20:44
*** d2m has quit IRC20:45
*** d2m has joined #zope3-dev20:46
*** d2m has joined #zope3-dev20:52
*** gumpa is now known as gumpa-away20:58
*** dlk has quit IRC21:00
*** nathany_ has quit IRC21:09
*** niemeyer_ has joined #zope3-dev21:11
*** niemeyer has quit IRC21:11
*** jinty has joined #zope3-dev21:14
*** jukart has left #zope3-dev21:16
*** niemeyer_ is now known as niemeyer21:16
*** mkerrin has quit IRC21:29
*** zbir has quit IRC21:31
*** RaFromBRC has joined #zope3-dev21:35
*** zbir has joined #zope3-dev21:37
*** benji has quit IRC21:43
efrerichmexiKON: ayt?21:45
*** admp has quit IRC21:53
mexiKONefrerich, yes21:57
efrerichmexiKON: Con you close 555 in the Collector? (I changed the domain name)21:59
efrerichCon => Can21:59
mexiKONefrerich, sure. in what revisions on whatb ranches?22:00
efrericha moment please22:02
efrerich3.3: 68116 trunk: 68187 (hdima) I didn't know that there was a Collector issue22:07
*** dunny has joined #zope3-dev22:08
efrerichI assume ther are more (old) issues which can be closed22:08
*** ignas has quit IRC22:11
mexiKONefrerich, done22:14
*** efrerich has quit IRC22:21
mexiKONdoes anyone know the difference between:22:41
mexiKONfrom pkgutil import extend_path22:41
mexiKON__path__ = extend_path(__path__, __name__)22:41
mexiKON    import pkg_resources22:41
mexiKON    pkg_resources.declare_namespace('zope')22:41
rockythe latter is setuptools safe perhaps ?22:45
mexiKONi wonder whether they're compatible, incompatible or whether the setuptools one simply extends what the other one does22:46
mexiKONcurrently, zope3's zope/ does the pkg_resources thing22:46
mexiKONwhereas zope2's zope/ does the pkgutil thing22:46
*** Aiste has quit IRC22:57
rockymy guess is pkg_resources is the clean setuptools way of doing it and pkgutil is the proprietary zope way23:00
mexiKONpkgutil is a std. python library23:00
mexiKONanyways, i wrote an email to the lists23:01
rockyoh, haha23:01
rockysorry, i'm obviously clueless here23:01
rockybut i do know (or at least thought) pkg_resources belongs with the peak stuff23:01
mexiKONpkg_resources is setuptools stuff23:03
mexiKONpart of the whole egg thing23:03
rockypeak stuff23:03
*** mgedmin has quit IRC23:09
*** Aiste has joined #zope3-dev23:25
*** niemeyer has quit IRC23:37
*** niemeyer has joined #zope3-dev23:39
*** zagy has quit IRC23:46
*** niemeyer has quit IRC23:59
*** niemeyer has joined #zope3-dev23:59

Generated by 2.15.1 by Marius Gedminas - find it at!