*** jhauser has quit IRC | 00:24 | |
Damascene | are metal macros 100% operational? i'm havign some slight issues on overriding slots, but not sure if it's just me. | 00:47 |
---|---|---|
J1m | as far as we know they are | 00:47 |
Damascene | is there a way to turn on advanced debugging mode for it? much to my chagrin, it seems like unlike TAL, METAL doesn't seem to error out very easily.. if at all. or i'm doing something terribly wrong heh. | 00:48 |
*** srichter has joined #zope3-dev | 00:55 | |
*** ChanServ sets mode: +o srichter | 00:56 | |
*** Aiste has quit IRC | 01:13 | |
Damascene | what's the diff between. views/standard_macros/page, context/@@standard_macros/page|view ? | 01:21 |
Damascene | for metal:use-macro | 01:21 |
Damascene | oh yeah throw in a views/standard_macros/view as well. | 01:21 |
J1m | don't use views | 01:21 |
J1m | use context/@@standard_macros | 01:21 |
Damascene | view or page? i'm just trying to get it so i can use my skins/template.pt | 01:22 |
Damascene | the macro slots i defined in skins/template.pt | 01:22 |
J1m | Use view if you want tabs | 01:22 |
Damascene | hm. i got a <html metal:use-macro="context/@@standard_macros/page"> and a <div metal:fill-slot="cat">ETC</div> in my index.pt. my skin/template.pt has a <metal:block define-macro="page"> and a <metal:block define-slot="cat">SOMETHING</metal:block> but it doesn't seem to override skins/template.pt curious on where i should look? i've tried a lot of diff combinations so far. | 01:30 |
*** porghar has joined #zope3-dev | 01:43 | |
porghar | hi there | 01:44 |
srichter | hi | 01:45 |
porghar | hi stephan | 01:46 |
porghar | i was precisely looking for your help :) | 01:46 |
srichter | :-) | 01:47 |
*** run|work has left #zope3-dev | 01:48 | |
porghar | i've been toying with zwiki, and i'm not sure if i'm doing something wrong | 01:48 |
porghar | is it supposed to work ok with latin-1 inputs? | 01:49 |
srichter | mmh, I can't remember, but I think it expects UTF-8 input | 01:50 |
srichter | unless your browser specifies otherwise | 01:51 |
porghar | i see | 01:51 |
*** `anthony has quit IRC | 01:52 | |
porghar | not sure of what i'm doing wrong then | 01:52 |
srichter | I remember there being some issues with non-ASCII inputs | 01:53 |
srichter | but this is certainly not zwiki-specific but a problem of the TextWidget in Zope 3 | 01:53 |
srichter | I think it would help brining it up on the Dev mailing list | 01:54 |
porghar | yup, i just wanted to check here first because i saw nothing on the list that looked similar | 01:54 |
porghar | and i've been digging for a couple of days now :) | 01:55 |
J1m | I doubt that: | 01:55 |
J1m | - zwiki uses a text widget | 01:55 |
J1m | - that there is a problem with non-ascii input to a text widget | 01:56 |
porghar | well | 01:56 |
porghar | not an expert in Zope3 by far, so you probably shouldnt pay much attention to this but... | 01:57 |
porghar | i've installed it on two boxes | 01:57 |
porghar | and tried to create a page with spanish accented characteres from three different ones | 01:57 |
porghar | with no success | 01:57 |
porghar | i get a unicodedecodeerror | 01:57 |
porghar | and btw, i get a similar error with bugtracker | 01:58 |
srichter | J1m: I am pretty sure that the text is sent Latin1 and Zope tries to decode it using UTF-8 | 01:59 |
J1m | Zope should be outputing the form in utf8 | 02:00 |
srichter | right, so we assume the browser sends the form also in UTF-8 | 02:00 |
srichter | do we actually specify the encoding in the form element? | 02:00 |
porghar | i've used both firefox and ie | 02:01 |
J1m | set set the charset to utf-8 in the headers | 02:02 |
J1m | we don't set it in the form tag | 02:03 |
porghar | ... sorry Jim... are you talking to me now? | 02:04 |
J1m | a browser is supposed to send the form in whatever encoding it got the form in | 02:04 |
J1m | I'm talking to both of you | 02:04 |
porghar | ok :) | 02:04 |
J1m | what is the unicode value of the character you are trying to send? | 02:04 |
porghar | hold on a second | 02:05 |
J1m | I got the same error. | 02:05 |
J1m | Crap | 02:06 |
porghar | the value is... | 02:06 |
J1m | well, wikipage has: | 02:06 |
J1m | html = str(source) | 02:06 |
J1m | trying a contact | 02:06 |
porghar | it's seems you haven't needed in the end | 02:06 |
porghar | i've tried hacking those lines too | 02:07 |
porghar | but i'm just a zope3-newbienewbie | 02:07 |
J1m | That code is just evil | 02:07 |
J1m | well, I just added a buddy with Arabic characters in it's address with no problem. | 02:08 |
J1m | So it's not a text widget bug. | 02:08 |
J1m | It sounds like zwiki is broken | 02:09 |
srichter | :-( | 02:09 |
srichter | probably some leftover from the old renderer | 02:09 |
*** hazmat has quit IRC | 02:09 | |
srichter | porghar: feel free to fix it | 02:09 |
J1m | The bug tracker is broken | 02:10 |
porghar | lol | 02:10 |
porghar | me? fix it? | 02:10 |
porghar | that wouldn't be a good idea :) | 02:10 |
porghar | i'm still trying to get the CA right | 02:10 |
porghar | btw, huge congrats to both of you | 02:11 |
porghar | (and all the rest) | 02:11 |
porghar | i'm amazed of what you're doing with zope3 | 02:11 |
porghar | so much, that i'm trying to make it used here at work | 02:11 |
J1m | srichter, the bug tracker is unusable | 02:13 |
J1m | Can't add bugs to it :( | 02:14 |
J1m | I don't know how porghar managed to test inputing non-ascii text to it. | 02:14 |
porghar | i'm using a zope3x-3.0.0 install | 02:15 |
porghar | and downloaded the package from the wiki | 02:15 |
porghar | it installs fine and works fine with ascii input | 02:15 |
*** hazmat has joined #zope3-dev | 02:16 | |
J1m | srichter, ayt? | 02:22 |
srichter | J1m: yep | 02:23 |
J1m | any idea what's up with bugtracker? | 02:23 |
srichter | nope | 02:23 |
srichter | in what respect? | 02:24 |
srichter | it should work afaik | 02:24 |
J1m | srichter, the bug tracker is unusable | 02:24 |
J1m | Can't add bugs to it :( | 02:24 |
srichter | :-( | 02:24 |
srichter | ok | 02:24 |
J1m | at least I can't | 02:24 |
srichter | I have to look at it | 02:24 |
porghar | i can't believe that after two days wondering what was *I* doing wrong... | 02:26 |
porghar | it was actually a couple of bugs in the packages :) | 02:26 |
porghar | ... makes me feel a little less stupid | 02:26 |
J1m | porghar, should should never assume you were doing something wrong with software | 02:26 |
porghar | lol | 02:26 |
porghar | the thing is, that assumption is normally right :p | 02:27 |
Damascene | yeah but i'm so bad at this stuff, it's usually my fault not the software's fault haha | 02:27 |
*** J1m has quit IRC | 02:28 | |
*** porghar has quit IRC | 02:33 | |
*** projekt01 has joined #zope3-dev | 02:47 | |
*** stub has joined #zope3-dev | 03:28 | |
*** hazmat has quit IRC | 04:40 | |
*** bradb has quit IRC | 04:48 | |
*** bradb has joined #zope3-dev | 04:52 | |
*** tvon has joined #zope3-dev | 04:53 | |
*** __gotcha__ has quit IRC | 04:57 | |
*** __gotcha has joined #zope3-dev | 04:59 | |
*** __gotcha__ has joined #zope3-dev | 05:00 | |
*** hazmat has joined #zope3-dev | 06:03 | |
*** stub has quit IRC | 06:28 | |
*** stub has joined #zope3-dev | 06:30 | |
*** hazmat has quit IRC | 07:10 | |
*** sashav has quit IRC | 07:16 | |
*** hazmat has joined #zope3-dev | 07:29 | |
*** zagy has joined #zope3-dev | 08:06 | |
zagy | moin | 08:07 |
*** hazmat has quit IRC | 08:33 | |
*** d2m has quit IRC | 08:41 | |
*** hazmat has joined #zope3-dev | 08:46 | |
*** Suresh-E has joined #zope3-dev | 08:56 | |
*** stu1 has joined #zope3-dev | 09:05 | |
*** stub has quit IRC | 09:06 | |
*** d2m has joined #zope3-dev | 09:14 | |
*** stu1 is now known as stub | 09:31 | |
*** sashav has joined #zope3-dev | 09:40 | |
*** jhauser has joined #zope3-dev | 10:16 | |
*** hazmat has quit IRC | 11:01 | |
*** MalcolmC has joined #zope3-dev | 11:11 | |
*** AJC has joined #zope3-dev | 11:38 | |
*** SteveA has quit IRC | 11:45 | |
*** SteveA has joined #zope3-dev | 11:46 | |
*** SteveA has quit IRC | 11:52 | |
*** SteveA has joined #zope3-dev | 11:52 | |
*** vlado has joined #zope3-dev | 12:00 | |
*** [nicknam] has joined #zope3-dev | 12:17 | |
*** [nicknam] is now known as apoirier | 12:17 | |
*** SteveA_ has joined #zope3-dev | 12:20 | |
*** SteveA has quit IRC | 12:20 | |
*** AJC has quit IRC | 12:20 | |
*** AJC has joined #zope3-dev | 12:21 | |
*** SteveA_ is now known as SteveA | 12:21 | |
*** mgedmin has joined #zope3-dev | 13:07 | |
*** alakdan has joined #zope3-dev | 13:16 | |
*** SteveA has joined #zope3-dev | 13:47 | |
*** alakdan has left #zope3-dev | 13:48 | |
*** SteveA_ has joined #zope3-dev | 13:58 | |
*** Aiste has joined #zope3-dev | 13:59 | |
*** SteveA has quit IRC | 14:01 | |
*** SteveA_ is now known as SteveA | 14:01 | |
*** `anthony has joined #zope3-dev | 14:03 | |
*** regebro has joined #zope3-dev | 14:03 | |
regebro | Hang on... because the date and datetime widgets uses tzinfo, I need to use it too, because otherwise dates can't be compared... | 14:09 |
regebro | And so find my tzinfo i need to do: | 14:10 |
regebro | from zope.app.datetimeutils import _tzoffset, tzinfo, DateTimeParser | 14:10 |
regebro | mytzinfo = tzinfo(_tzoffset(DateTimeParser._localzone, None) / 60) | 14:10 |
regebro | Isn't that just a tad bit complicated? Is there an easier way to do this? | 14:10 |
regebro | Evidently not. And I even simplified it by ugly-using DateTimeParsers class attribute. ;) | 14:15 |
mgedmin | does that bit handle daylight savings time? | 14:19 |
*** mgedmin has quit IRC | 14:25 | |
regebro | Yup, because DateTimeParser._localzone is DST aware. | 14:27 |
*** niemeyer has joined #zope3-dev | 14:31 | |
*** Aiste has quit IRC | 14:33 | |
* VladDrac 's trying to figure out why he doesn't get a view / preview tab | 14:39 | |
*** srichter has quit IRC | 14:44 | |
*** tvon has quit IRC | 14:51 | |
*** faassen has joined #zope3-dev | 15:15 | |
regebro | Sigh, and dates are always timezone naiv, and can't be compared with datetimes that have timezones. | 15:24 |
*** stub has left #zope3-dev | 15:32 | |
regebro | Or maybe not.. | 15:36 |
*** mgedmin has joined #zope3-dev | 15:37 | |
`anthony | regebro: datetimes and timezones are just plain evil and hard. | 15:38 |
regebro | Yeah, so I notice. :/ | 15:38 |
Damascene | hey regebro, ever use METAL? | 15:40 |
regebro | As is metal:use-macro, yes. | 15:42 |
regebro | Otherwise, no, Damascene. Unless you mean like, metal forks. Hohoho. ;) | 15:42 |
SteveA | `anthony: a veritable can of worms. | 15:43 |
*** tvon has joined #zope3-dev | 15:44 | |
`anthony | SteveA: There's a reason grownups use UTC for everything <wink> | 15:46 |
regebro | It would be MUCH easier if you could just make a particular tzinfo the default, so that all times are tz-aware. | 15:48 |
regebro | I'm currently going through all my code to find all places where I create datetimes or times that do not have timezones... | 15:48 |
`anthony | regebro: Really, really, really: Use UTC everywhere, and convert to a timezone at display-time. | 15:49 |
`anthony | Timezones are only for display. | 15:49 |
regebro | Tell that to Zope3. :p | 15:49 |
`anthony | You will find your code is much saner and much more robust. | 15:49 |
`anthony | regebro: I haven't looked too closely at Z3, but Z2 works fine in UTC. | 15:49 |
`anthony | s/Z3/Z3's timezone mechanisms/ | 15:50 |
`anthony | if all else fails, set TZ=UTC before starting Z3 | 15:50 |
SteveA | i'd say use UTC everywhere except where you want to use naive time because you are actively uninterested in timezone. | 15:50 |
regebro | Yeah, but datetime works quite differently. | 15:50 |
`anthony | SteveA: Even then. You might _think_ you don't care about timezones, but later down the track you will probably get bitten. | 15:51 |
*** srichter has joined #zope3-dev | 15:51 | |
*** ChanServ sets mode: +o srichter | 15:51 | |
`anthony | I've seen at least half-a-dozen other projects get bitten by this. | 15:51 |
SteveA | there's a bunch of calendaring applications where you really want to explicitly not care about timezones | 15:51 |
* VladDrac wraps his brain around too much zope3 stuff at once | 15:51 | |
regebro | I am actively uninterested in it, but zope gives me tz-aware times. So all my times need to be tz-aware. Using UTC doesn't really help, becaus ethat is still a timezone. | 15:51 |
`anthony | SteveA: Not so. A calendar _must_ care about timezones. | 15:51 |
`anthony | "Set an event to go off this time next week". Ok, what happens if that "week" includes a daylight savings time switch? | 15:52 |
SteveA | if it is my personal calendar, and i want to be woken up at 8am, i want it to be 8am in the timezone i am in | 15:53 |
SteveA | if it travel, i want it to be 8am local time | 15:53 |
regebro | Well, if it IS timezone-aware, wouldn't it go off one hour off? | 15:53 |
regebro | Q: What does iCal do? | 15:53 |
`anthony | regebro: But you might want that. You might be instead saying "24 * 7 hours from now". That's what I mean by "you need to pay attention to it now" | 15:53 |
SteveA | adding timezone information to that, and adding in naive programmers, you get a system that doesn't work well because it is taking responsiblity for too much information | 15:53 |
regebro | `anthony: Sure, but that must be a very unusual case. | 15:54 |
`anthony | SteveA: So what happens to the event that's registered at 2.30am on the night of the DST switch (here, DST switch is at 2/3am) | 15:54 |
regebro | I don't really care if my calendar understands timezones or not. Any way, it's a lot of bother. | 15:55 |
`anthony | regebro: You'd be horribly surprised to see how often daylight savings fucks things up. | 15:55 |
regebro | `anthony: No I wouldn't. | 15:55 |
SteveA | `anthony: the software needs to be down for maintenance | 15:55 |
`anthony | SteveA: Yuk. | 15:55 |
regebro | I've been doing timezone aware software for many years. | 15:56 |
`anthony | I take an absolutely hard-line on timezone issues. Any time stored with a "timezone" is a bug ;) | 15:56 |
`anthony | unless that "timezone" is UTC, aka +0000 | 15:56 |
regebro | I would agree on that. | 15:57 |
`anthony | regebro: I also find it clarifies issues a lot if you simply regard "timezone" as another display setting, like "language" | 15:57 |
`anthony | or "font" <wink> | 15:57 |
MalcolmC | anthony: What if a user of an international system chooses a time, and that time has to continue to come out as their local time even when their local timezone changes? | 15:58 |
regebro | But, how on earth do I handle both tz-aware and non-tz-aware datetimes? | 15:58 |
MalcolmC | anthony: Do you then force the time to UTC and store their timezone separately, just to prove a point? | 15:58 |
SteveA | regebro: they are two totally different things, that's all | 15:58 |
SteveA | regebro: a non-tz-aware datetime is more like a timedelta, really | 15:59 |
regebro | Yeah, but I need to handel them both, as if they are one. | 15:59 |
SteveA | no you don't | 15:59 |
regebro | Yeah, well, good. You come over here and write this program then. ;) | 16:00 |
regebro | But I'll start with seeing if I can convince Zope3 not to give me tzaware dates, firstly... | 16:01 |
SteveA | where does it give you these things? | 16:02 |
SteveA | you mean from forms? | 16:02 |
regebro | Yup. I can strip it of tzinfo, I guess. I tried that before but that seemed complicated. | 16:03 |
SteveA | you want a field type that is a naive datetime field | 16:04 |
SteveA | because it is a totally different thing to a utc datetime | 16:04 |
SteveA | anthony is right that utc datetime is by far the most useful in almost all situations | 16:04 |
regebro | SteveA, actually, that part might fix itself when I have proper widgets fordate and time, instead of a date input field. | 16:05 |
`anthony | MalcolmC: No. If you want to let the user change timezones and have it affect existing stored times, then you need to make sure you do the right thing then. | 16:05 |
regebro | I mean string input field. | 16:05 |
*** mgedmin_ has joined #zope3-dev | 16:06 | |
mgedmin_ | I'm a bit unhappy that datetime does not have a tzinfo object for UTC | 16:07 |
mgedmin_ | and that datetime.datetime.utcnow() returns a datetime object with tzinfo=None | 16:07 |
*** Voblia_ has joined #zope3-dev | 16:07 | |
*** gintas has joined #zope3-dev | 16:07 | |
*** bskahan has joined #zope3-dev | 16:08 | |
Damascene | oh boy. if i use my custom skin in the latest svn, the w3.org validator gets a 404. if i go to that URL manually, it works fine... boggles the mind. | 16:13 |
*** J1m has joined #zope3-dev | 16:14 | |
*** mgedmin has quit IRC | 16:18 | |
*** mgedmin_ is now known as mgedmin | 16:19 | |
regebro | mgedmin_: That's because the default datetime implementation has no tzinfo implementation at all. | 16:25 |
regebro | so tzinfo must be None. | 16:25 |
regebro | A good default set of tzinfos would be very beneficial to Python I think. | 16:26 |
mgedmin | well, the datetime module has an abstract tzinfo class | 16:27 |
mgedmin | it could also have a concrete class for UTC | 16:27 |
regebro | Yeah, you might be right. | 16:28 |
regebro | i was thinking it needs a more comple implementation, but just a UTC timezone would be good. | 16:28 |
Damascene | hm. i wonder WHY Zope3 might spit out HTTP/1.1 404 Not Found | 16:31 |
Damascene | Date: Tue, 25 Jan 2005 14:29:56 GMT | 16:31 |
Damascene | but then still display the contents | 16:31 |
mgedmin | Damascene, what does the error log say? | 16:31 |
Damascene | that's if i use a custom skin. maybe i setup my custom skin improperly... | 16:31 |
Damascene | mgedmin: 404, but the content displays fine. ;) | 16:32 |
Damascene | no traceback or anything | 16:32 |
Damascene | basically if i didn't use the w3.org validator, i'd never have seen or thought it was a 404 because the page displays. | 16:33 |
Damascene | i manually telnetted to the system. if i use say ++skin++ZopeTop/ it does show 200 Ok | 16:33 |
Damascene | i just switch to ++skin++fc/ and boom 404, but still displays the page. | 16:33 |
Damascene | so either i setup the skin improperly... (not sure .. i just did package include=".skin" in the browser, added in a <layer> command and <skin> command in the skins' configure.zcml...) | 16:35 |
Damascene | displays the page according to my skin's template.pt... (although i've been having probelms with getting my macro slots to fill, i wonder if this is related). | 16:37 |
*** Suresh-E has left #zope3-dev | 16:37 | |
*** SteveA_ has joined #zope3-dev | 16:45 | |
*** `anthony has quit IRC | 16:47 | |
*** `anthony has joined #zope3-dev | 16:51 | |
*** [apoirie] has joined #zope3-dev | 16:53 | |
Damascene | okay. does anyone have another public site using the Zope3 SVN I can test to see if it showsup with 404 but still 'displays' properly? | 17:01 |
Damascene | but needs a custom skin. | 17:02 |
*** SteveA has quit IRC | 17:07 | |
*** apoirier has quit IRC | 17:13 | |
*** zopepaul has joined #zope3-dev | 17:37 | |
*** eaon has joined #zope3-dev | 17:41 | |
*** eaon has left #zope3-dev | 17:41 | |
*** sashav has quit IRC | 18:02 | |
*** zopepaul has quit IRC | 18:11 | |
*** gintas has quit IRC | 18:35 | |
*** jhauser_ has joined #zope3-dev | 18:53 | |
*** jhauser has quit IRC | 19:05 | |
*** bskahan has quit IRC | 19:09 | |
*** bskahan has joined #zope3-dev | 19:18 | |
Voblia_ | is there a way to check permissions of some view (permissions that are set in zcml file) in the code of a view? | 19:25 |
*** Voblia_ is now known as Voblia | 19:28 | |
mgedmin | Voblia, try view = zope.component.getView(object, name, request) | 19:30 |
* mgedmin pauses | 19:31 | |
mgedmin | will getView succeed if the authenticated user does not have permission to access that view? | 19:31 |
mgedmin | will it return a security proxied view? | 19:31 |
*** sashav has joined #zope3-dev | 19:31 | |
*** Aiste has joined #zope3-dev | 19:33 | |
mgedmin | yes it will | 19:34 |
*** zagy has quit IRC | 19:35 | |
*** hazmat has joined #zope3-dev | 19:37 | |
mgedmin | uhh, I think you can then call zope.security.proxy.getChecker(view).check_getattr(view, '__call__') and see whether it raises an exception | 19:37 |
mgedmin | eek, there should be a better way to get an answer to the question "can I access attribute foo of object bar?" | 19:38 |
*** tvon has quit IRC | 19:38 | |
*** MalcolmC has left #zope3-dev | 19:43 | |
*** tvon has joined #zope3-dev | 19:44 | |
*** vlado has quit IRC | 19:54 | |
*** Heff has joined #zope3-dev | 20:02 | |
*** AJC has quit IRC | 20:02 | |
*** Heff is now known as AJC | 20:02 | |
* mgedmin is slightly annoyed that verifyObject() returns True *or* raises an exception | 20:18 | |
* mgedmin thinks that there are two sane models: A) returning True or False, b) raising an exception or returning None | 20:18 | |
* J1m agrees with mgedmin | 20:19 | |
mgedmin | are there any caveats with skins and functional doctests? | 20:36 |
*** bskahan has quit IRC | 20:45 | |
*** regebro has quit IRC | 20:49 | |
*** [apoirie] has quit IRC | 20:51 | |
*** Aiste has quit IRC | 21:01 | |
mgedmin | ++skin++ does not work in functional doctests! | 21:07 |
*** tvon has left #zope3-dev | 21:08 | |
Damascene | all ++skin++s? or just the custom one you built? | 21:14 |
Damascene | i.e. does ++skin++ZopeTop work? | 21:14 |
Damascene | i'm just curious if this is related to the issue i ran into where my custom skin would return HTTP 404 but the content would display. | 21:14 |
mgedmin | ++skin++ZopeTop does not work | 21:15 |
Damascene | oh | 21:15 |
Damascene | ah well. i guess i'm all alone in my wack issue then. haha | 21:15 |
*** hazmat has quit IRC | 21:22 | |
J1m | ++skin++ZopeTop works fine for me | 21:23 |
mgedmin | it works in a browser, but not in a functional doctest | 21:24 |
J1m | ah | 21:25 |
mgedmin | I think it is because functional tests create a new BrowserRequest class | 21:25 |
mgedmin | and say that it implements the default skin | 21:25 |
J1m | I frequently use the ebug skin when debugging functional doctests | 21:25 |
J1m | I frequently use the debug skin when debugging functional doctests | 21:25 |
mgedmin | hm | 21:25 |
* mgedmin tries to construct a short testcase | 21:27 | |
mgedmin | it works | 21:27 |
Damascene | actually does someone have a zope 3 svn that i can just publically access with one of your custom skins? i just want to verify it isn't showing 404 like mine. :( | 21:33 |
mgedmin | Damascene, I've used custom skins in Zope 3 apps, and I do not remember having that error | 21:35 |
mgedmin | although I don't believe I ever explicitly checked the status code | 21:35 |
Damascene | yeah, that's why i wanted to test it on someone else's setup who knows what they are doing. ;) | 21:35 |
Damascene | if it works on someone else's setup, then clearly i've borked something up (as usual). | 21:36 |
mgedmin | HTTP/1.0 200 Ok | 21:36 |
mgedmin | my skins work in a browser, but don't work in functional doctests :-) | 21:38 |
Damascene | ah well. i guess i did something retarded then. you using the SVN or 3.0.0? | 21:40 |
mgedmin | svn | 21:41 |
*** faassen has quit IRC | 21:43 | |
Damascene | okay teh problem is somehow my errant skin/template must be screwing it up. thanks, at least i know it's definitely on my end. ;) probably the skin template | 21:44 |
mgedmin | is the ZopeTop skin derived from rotterdam? | 21:56 |
mgedmin | yes | 21:57 |
mgedmin | I think that explains why ZopeTop works in functional doctests while my custom skin doesn't | 21:57 |
mgedmin | I use a BeforeTraversalEvent subscriber that checks whether event.object provides a certain interface | 21:57 |
mgedmin | and if it does, the subscriber calls applySkin(event.request, MyCustomSkin) | 21:57 |
Damascene | hm. in srichter's book. <html metal:use-macro="views/standard_macros/page"> | 21:57 |
Damascene | however, that macro page defines the doctype. | 21:58 |
Damascene | but the doctype has to be defined before the <html> tag. a catch-22. | 21:58 |
mgedmin | I added a debugging print that prints list(providedBy(event.request).interfaces()) after calling applySkin | 21:58 |
mgedmin | and I see that in functional doctests the request provides both my skin and Rotterdam | 21:58 |
mgedmin | while in real life it does not provide Rotterdam | 21:58 |
mgedmin | I blame zope.interface.classImplements(request_cls, _getDefaultSkin()) in zope.app.tests.functional | 21:59 |
mgedmin | Damascene, metal:use-macro will replace the <html> element in your template with whatever is defined in the macro | 22:00 |
mgedmin | so if the macro has something like <metal:block define-macro="page"><!DOCTYPE ...><html>...</html></mt | 22:00 |
mgedmin | </metal:block> | 22:00 |
mgedmin | then it will produce correct output | 22:00 |
Damascene | ah ok! | 22:00 |
Damascene | thansk for the sanity check. a tiny typo of mine forced it to not appear that way (even though what you said makes sense and is what the docs said too hehe) | 22:02 |
*** hazmat has joined #zope3-dev | 22:03 | |
mgedmin | the Debug skin also includes the rotterdam layer | 22:04 |
mgedmin | therefore more specific interfaces win and the bug is not noticeable with Debug or ZopeTop skins | 22:04 |
* mgedmin found a simple way to reproduce his problem | 22:10 | |
mgedmin | J1m, try http("GET /++skin++Basic HTTP/1.1\n\n") in a functional doctest | 22:11 |
mgedmin | you will see that the rotterdam skin gets applied (the output does not mention zopetopBasic.css but mentions zope3xmltree and such that come from the rotterdam skin | 22:12 |
J1m | I'll take your word for it. | 22:12 |
mgedmin | I was wrong once already | 22:12 |
J1m | I'm pretty busy on something else | 22:13 |
mgedmin | ok | 22:13 |
mgedmin | perhaps I should just file a collector issue | 22:13 |
J1m | That would be good | 22:13 |
* mgedmin does so | 22:14 | |
*** zagy has joined #zope3-dev | 22:17 | |
mgedmin | done: http://zope.org/Collectors/Zope3-dev/353 | 22:24 |
*** SteveA_ is now known as SteveA | 22:39 | |
*** zagy has quit IRC | 22:46 | |
*** niemeyer has quit IRC | 23:03 | |
*** frerich has joined #zope3-dev | 23:17 | |
frerich | quit | 23:19 |
*** mgedmin has quit IRC | 23:33 | |
*** bskahan has joined #zope3-dev | 23:34 | |
*** frerich has quit IRC | 23:42 | |
Damascene | well what do you know. that silly context/@@view_get_menu/fc_mainnav is what caused ALL my problems. error 404, and METAL not working. ;) | 23:48 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!