| *** alga has quit IRC | 00:14 | |
| *** tvon has quit IRC | 00:28 | |
| *** tvon has joined #zope3-dev | 00:29 | |
| *** palmTree has joined #zope3-dev | 00:34 | |
| *** cri71 has joined #zope3-dev | 00:34 | |
| *** cri71 has left #zope3-dev | 00:34 | |
| *** tvon has quit IRC | 00:37 | |
| *** SteveA has joined #zope3-dev | 00:38 | |
| *** tvon has joined #zope3-dev | 00:51 | |
| *** niemeyer has quit IRC | 00:58 | |
| *** palmTree has quit IRC | 01:06 | |
| *** admp has quit IRC | 01:36 | |
| *** ignas has joined #zope3-dev | 01:40 | |
| KurtB | Okay, I have a running zope3. I'd be foreever greatful if someone would clue me into docs that explain how I wedge the pythonpath pointer to an application into my instance. :-) | 01:45 |
|---|---|---|
| Arnia | symlink into /usr/lib/python? | 01:46 |
| philiKON | KurtB, in zope.conf, you can use the python-path directive | 01:47 |
| KurtB | ah... | 01:47 |
| philiKON | (i think... checking...) | 01:48 |
| KurtB | cool... I've been asked to get a product, schooltool, running... and this is my first forray into zope3. | 01:48 |
| th1a | KurtB: Are you trying to run SchoolTool or SchoolBell? | 01:48 |
| KurtB | th1a, er.... | 01:49 |
| KurtB | schoolbell | 01:49 |
| KurtB | :-) | 01:49 |
| th1a | It is a little confusing. | 01:49 |
| KurtB | ya. heh. :-) | 01:49 |
| philiKON | KurtB, but why don't you install the libraries into $INSTANCE_HOME/lib/python ? | 01:49 |
| KurtB | my instance... | 01:50 |
| KurtB | The SchoolBell product... does not really explain what goes where after running it's "make" stuff. | 01:51 |
| th1a | It will run as a standalone app if you want. | 01:52 |
| KurtB | philiKON, but I'll give it a whirl and start looking to figure out how to get it's libraries into $INSTANCE_HOME/lib/python | 01:52 |
| th1a | KurtB: I'm a little confused about what you're trying to get it to do. | 01:53 |
| KurtB | th1a, I see that, I think... but don't I need to install another zope3, do I? | 01:53 |
| KurtB | that's what the schoolbell docs seem to infer. | 01:53 |
| th1a | No. | 01:53 |
| th1a | Which ones? | 01:54 |
| KurtB | http://www.schooltool.org/schoolbell/SourceInstallForLinux | 01:54 |
| KurtB | and the docs in the tarball I downloaded. | 01:54 |
| philiKON | KurtB, if it has a setup.py, you can say: python setup.py install --home $INSTANCE_HOME i think | 01:54 |
| KurtB | Sorry, I am new to zope3. | 01:55 |
| philiKON | that's ok | 01:55 |
| KurtB | Ahh.. philiKON ... I'll give that a whirl. That feels right. | 01:55 |
| KurtB | :-) | 01:55 |
| th1a | KurtB: Yeah, that's pretty misleading. | 01:55 |
| th1a | I'll fix it on the site. | 01:55 |
| KurtB | th1a, are you attached to that project? | 01:55 |
| KurtB | Ah.. i guess so. :-) | 01:55 |
| th1a | I manage it. | 01:56 |
| th1a | I guess the notes say that Zope X3 is included, but you have to read it carefully to see that. | 01:57 |
| KurtB | someone from the college of education asked me, "Since you already run zope, can you make this run so we can test it?" | 01:57 |
| th1a | College of Education where? | 01:57 |
| KurtB | University of louisville. er... uh... go cards! | 01:57 |
| KurtB | Apparently, basketball gets funding here. | 01:57 |
| th1a | Interesting. | 01:58 |
| KurtB | and training. | 01:58 |
| KurtB | The rest of us gotta just figure it out. | 01:58 |
| KurtB | :-) | 01:58 |
| th1a | Were they interested for themselves or K12 schools? | 01:58 |
| KurtB | Themselves. | 01:59 |
| KurtB | I also saw something about Academic Assessment Tracking on the bounty page. | 01:59 |
| th1a | Yes. | 02:00 |
| KurtB | The university is looking at products to handle that. | 02:00 |
| th1a | For the university? | 02:00 |
| KurtB | I just sat thru a Blackboard presentation today... for the university. | 02:00 |
| *** bradb has quit IRC | 02:00 | |
| KurtB | what an awful product. | 02:00 |
| KurtB | imho, that is. | 02:01 |
| th1a | We could move this over to #schooltool ... | 02:01 |
| KurtB | ok. | 02:01 |
| KurtB | philiKON, thanks for the tip... trying it now | 02:01 |
| *** bradb has joined #zope3-dev | 02:22 | |
| *** ignas has quit IRC | 03:01 | |
| *** Arnia has left #zope3-dev | 03:09 | |
| *** garrett-smith has left #zope3-dev | 03:11 | |
| *** Arnia has joined #zope3-dev | 03:16 | |
| srichter | KurtB: Blackboard sucks | 03:25 |
| srichter | my dream was and is to develop a Zope 3 version of it | 03:25 |
| Arnia | Blackboard is horrible... but Durham seems to love it :/ | 03:25 |
| Arnia | Please replace it :) | 03:25 |
| srichter | Tufts uses it heavily too | 03:26 |
| srichter | it gets the Job done, but it could be much better | 03:26 |
| Arnia | Well... all the staff in Durham hate it... all the students hate it. The only person who likes it is Kate Boardman but she's in charge of eLearning software on the network | 03:26 |
| srichter | I am still searching for an app to develop atop Zope 3 in my spear time | 03:26 |
| srichter | the blackboard replacement is on the top of my list | 03:27 |
| Arnia | That would be a great example to use for Isia... | 03:27 |
| * Arnia tries to decode zope.form | 03:27 | |
| srichter | well, currently there is no real alternative to it, unfortunately | 03:27 |
| Arnia | zope.app.form | 03:27 |
| Arnia | I have pagelets running now... with conditions etc. We have a skin using pagelets to control the flowing of every components. Next step, turn unify pagelets and form rendering. Down with hardcoded magic! ;) | 03:29 |
| srichter | Arnia: do you use the pagelet code from zope.app.pagelet? | 03:30 |
| srichter | BTW, Gary is working on a zope.app.form reqrite | 03:30 |
| Arnia | srichter: No... I'm using my own code which I wrote last summer. isia.siesia.schema | 03:31 |
| srichter | I see | 03:31 |
| Arnia | srichter: The zope.app.pagelet code is instructive and its prompted me to consider rewriting my own code... but it misses a few vital features. | 03:31 |
| Arnia | And the maintainer apparently doesn't see them as important | 03:32 |
| srichter | well, you should improve on the code in the zope core | 03:32 |
| Arnia | I'm not sure the needs overlap | 03:32 |
| srichter | projekt01, who wrote the code, will not mind | 03:32 |
| srichter | we need people to review that code badly | 03:32 |
| Arnia | The Zope Core pagelets are treated like portlets... rather than being a part of a fundamental shift in how views are generated | 03:32 |
| Arnia | In effect, a pagelet is just a subsort of a view, with extra bits of information on (such as weight, condition, ESI cache info)... but they can be nested. I'm still considering the idea that forms are another sort of pagelet | 03:34 |
| srichter | well, I am not sure the entire pipelining is the solution | 03:35 |
| Arnia | We don't pipeline | 03:35 |
| Arnia | Not in the running code | 03:35 |
| Arnia | It inserts pagelets from the top down... each region responsible for adding its own pagelets (region is IMO a better name than 'slot' which is associated with portlets, a concept not eliminated or subsumed by pagelets) | 03:36 |
| philiKON | how is a region differnet from a slot? | 03:36 |
| Arnia | Portlets are semantically different from pagelets... portlets are secondary content elements which are flowed together in slots. Pagelets are chunks of page render. Portlets should be treated differently in my mind -- for example giving users the choice of which portlets to display, whereas pagelet display and region placement is a sysadmin's decision. | 03:38 |
| philiKON | ok... | 03:39 |
| philiKON | then my understanding of pagelet was right | 03:39 |
| philiKON | a chunk of the page we want to render | 03:39 |
| Arnia | In Siesia LF, *everything* is generated by pagelets. We're looking to have pagelets automatically add ESI information around themselves for example (if the administrator wants) so that the caching becomes selective and more effective | 03:39 |
| philiKON | that's a good approach | 03:40 |
| philiKON | like srichter said, itwould be great if we had some of these ideas flow back into zope.app.pagelet | 03:40 |
| philiKON | btw, I too want EVERYTHING to be done by pagelets | 03:40 |
| KurtB | srichter, blackboard has won the hearts and minds of $$administrators$$ through marketing. | 03:40 |
| philiKON | basically, i want to castrate that standard_macros junk to a minimum | 03:40 |
| srichter | KurtB: yep | 03:40 |
| srichter | I think the boston skin is a perfect sandbox for those ideas | 03:41 |
| Arnia | The main motivation for using such a concept is that we have a very modular system in terms of functionality but a monolithic view generation system | 03:41 |
| Arnia | srichter: The Siesia LF skin is better in terms of markup... believe me | 03:41 |
| Arnia | srichter: Mikey has out-done himself | 03:42 |
| srichter | but it is not in the Zope Core, so it does not exist for me as an option | 03:42 |
| Arnia | It uses pagelets wonderfully, to make accessibility easy to maintain | 03:42 |
| KurtB | Well, my first forays into plone 3 have not been overly painful. I'm starting to get it. :-) Now, going home to clean stalls. | 03:42 |
| Arnia | And its the most flexible skinning with the lightest markup I've seen. | 03:43 |
| KurtB | oh, don't get me started on accessibility... after talking about blackboard! ;-) | 03:43 |
| philiKON | KurtB, s/plone/zope/ | 03:43 |
| srichter | the only person that has contributed to UI design in recent years is roger, so he has my full support till other people start contributing | 03:43 |
| KurtB | heh. | 03:43 |
| philiKON | Arnia, so, bring it on! i want that in zope 3 for everyone to use | 03:43 |
| * KurtB is brain dead after being bludgeoned by zope3. | 03:43 | |
| philiKON | (btw, what's blackboard) | 03:43 |
| srichter | philiKON: a WEb app to manage courses | 03:44 |
| Arnia | philiKON: We're working on it. We have project management and stuff and are trying to get everything suitable for others to use (docs etc) | 03:44 |
| srichter | document upload, grades, discussion board, ... | 03:44 |
| KurtB | philiKON, oh, just a very overpriced cms with a couple of "educational" widgets installed, and then sold for a lot of money. | 03:44 |
| philiKON | Arnia, if it were integrated into z3, that would be a lot better. think of the synergy effects... | 03:44 |
| KurtB | Thanks guys! See ya' tomorrow. | 03:45 |
| srichter | KurtB: bye | 03:45 |
| *** KurtB has quit IRC | 03:46 | |
| * tvon notes that SchoolTool would love some contributions related to Blackboard replacement (or anything else) | 03:46 | |
| Arnia | philiKON: But Z3 has committed to Boston now? | 03:46 |
| tvon | Boston can change if the core improves | 03:46 |
| srichter | tvon: yeah, if I would rewrite blackboard, I would start with the relationship manager from SteveA | 03:47 |
| philiKON | Arnia, boston is something that was started by projekt01 and srichter impulsively | 03:48 |
| philiKON | Arnia, we'll see where it goes | 03:48 |
| Arnia | And how many skins can zope.app support? :p | 03:48 |
| philiKON | well, boston is just an experiment as far as i understand | 03:49 |
| tvon | srichter: schooltool has a relationship system.. probably from SteveA since he rewrote schooltool a lil while ago | 03:49 |
| srichter | tvon: yep | 03:49 |
| philiKON | Arnia, just like rotterdam was a temporary thing ;) | 03:49 |
| tvon | srichter: I've wondered why that hasn't made it into core, it's very nice | 03:50 |
| Arnia | philiKON: We are writing a HIG too... which works nicely with the accessibility and pagelets | 03:50 |
| philiKON | Arnia, seriously, i think efforts can be merged here... it's great that zope.app.pagelet inspired you, but your ideas should also inspire zope.app... | 03:50 |
| philiKON | HIG? | 03:50 |
| srichter | tvon: because SteveA never contributed it | 03:50 |
| Arnia | philiKON: Uhh... I wrote my pagelets months before Roger afaict | 03:50 |
| philiKON | Arnia, no, i meant your statement from above | 03:51 |
| Arnia | philiKON: Human Interface Guidelines | 03:51 |
| philiKON | that you looked at roger's pagelets and considered to rewrite some of your code | 03:51 |
| philiKON | anyway, yes, i was quite disappointed to see roger also implementing pagelets when you guys already had an implementation | 03:51 |
| Arnia | philiKON: Ah, ok. I'm just thinking about how to go about this... | 03:51 |
| philiKON | but, as it turned out, roger contributed to z3 and is actively using them | 03:51 |
| tvon | srichter: ah, well that's no fun.. I'll talk to folks about getting it contributed | 03:51 |
| projekt01 | Arnia, It's a port of your concept, it's really the same. It's just different implemented. | 03:52 |
| philiKON | hey, there he is | 03:52 |
| philiKON | still awake, eh? | 03:52 |
| projekt01 | Yup | 03:52 |
| projekt01 | Of corse | 03:52 |
| Arnia | projekt01: Well... its not exactly the same... I'm curious to know why you don't include conditions and call the regions slots. | 03:52 |
| Arnia | projekt01: I thought long and hard about those things before making those decisions... | 03:53 |
| philiKON | i think both zope.app.pagelet and zope.app.boston are far from perfection. i hope that fresh ideas can still be woven into them | 03:53 |
| philiKON | that was my good night statement | 03:53 |
| philiKON | g'night all | 03:53 |
| Arnia | night | 03:53 |
| srichter | boston and pagelets are not going to make it into 3.1, so there is plenty of time to review and improve it for 3.2 | 03:54 |
| projekt01 | Arnia, I wasn't sure if conditions are the right concept | 03:54 |
| projekt01 | They are sued in ZCML | 03:54 |
| *** eaon has joined #zope3-dev | 03:54 | |
| projekt01 | We don't use this much configureation in ZCML right now | 03:54 |
| Arnia | projekt01: Yes, because they're a deployment decision | 03:54 |
| * th1a notes that SchoolTool is going to need some kind of serious pagelets/portlets action soon. | 03:54 | |
| Arnia | projekt01: And because pagelets need conditions for other reasons | 03:55 |
| srichter | Arnia: saying why did you not do this or that is not fair. make a proposal, formal or informal, and then intergrate the feature | 03:55 |
| projekt01 | But this is not what we like to have in ZCML | 03:55 |
| Arnia | projekt01: Not all pagelets are templates after all | 03:55 |
| srichter | I am tired of seeing people jsut talking and not acting | 03:55 |
| Arnia | projekt01: Where else can it go? | 03:55 |
| eaon | projekt01: but menus support that too? | 03:55 |
| philiKON | projekt01, why not have the condition in zcml? would it hurt there? | 03:55 |
| Arnia | srichter: I am acting. I am writing code, I'm working on it. I'm curious as to why another decision was taken from the one I was taking | 03:55 |
| projekt01 | eaon, where? | 03:55 |
| Arnia | srichter: That is not just talking, that's trying to understand what has been done before so I can integrate my ideas like you wish | 03:56 |
| eaon | give me a sec | 03:56 |
| projekt01 | eaon, ok | 03:56 |
| srichter | projekt01: menus have a condition attribute | 03:56 |
| eaon | hello everyone by the way :) | 03:56 |
| philiKON | hi eaon | 03:56 |
| srichter | that evaluates a TALES expression to true or false | 03:57 |
| eaon | (it's the condition attribute is called filter) | 03:57 |
| philiKON | right. a simlair thing for pagelets would be quite useful | 03:57 |
| Arnia | Yes, that's what my conditions attribute does | 03:57 |
| philiKON | i can imagine use cases | 03:57 |
| Arnia | Possibly need an ESI condition too... need to think some more about that | 03:57 |
| philiKON | maybe we can keep ESI out of this for now | 03:57 |
| projekt01 | srichter, yes conditions are for to set True or False | 03:58 |
| philiKON | i think we probably want special views (and views on pagelets) for ESI | 03:58 |
| projekt01 | This is the only different (or missing future) to Sessia | 03:58 |
| eaon | ESI should be kept in mind for the future though | 03:58 |
| Arnia | philiKON: Its important for some things I wish to do... which is why I'm considering it. | 03:58 |
| philiKON | right, but we shoudl start out simple | 03:59 |
| projekt01 | I implemented pagelets/pagelet and pagedata which is all what we need for future concept based on viewlet, pagelet, portlets or whatever we like to implement | 03:59 |
| eaon | thats what we're doing :) | 03:59 |
| philiKON | eaon, good :)... ESI support will likely need a new set of views anyway | 04:00 |
| projekt01 | Zope.app.apagelet is a generic implementation of Sessia's pagelets | 04:00 |
| Arnia | philiKON: I'm not convinced by the need for new views... | 04:01 |
| Arnia | projekt01: Generic? How? | 04:01 |
| Arnia | But *shrugs* :) | 04:01 |
| eaon | (Siesia btw - yes, a little hard to remember, sorry) | 04:01 |
| projekt01 | It's wide open for future applications and is built on a pure mulitadapter concept | 04:01 |
| Arnia | Ours were multiadapters | 04:01 |
| Arnia | s/were/are ;) | 04:02 |
| projekt01 | There is nothing special it offers more or less only directives for register this multiadapters | 04:02 |
| projekt01 | On the right interfaces | 04:02 |
| * philiKON really goes to bed now | 04:02 | |
| projekt01 | All other parts are up to the developer what pagelets portlets or viewlets can be | 04:03 |
| projekt01 | And how they get lookuped | 04:03 |
| Arnia | projekt01: Exactly like ours then :) | 04:03 |
| projekt01 | I added just a sample called pageletchooser where such a implementation is shown | 04:03 |
| projekt01 | Yup, excatly the same | 04:03 |
| Arnia | Multiadapters to an interface... the pagelet directive is just an easy way to specify template based pagelets | 04:03 |
| Arnia | Can your pagelets nest? | 04:04 |
| projekt01 | To (context, request, slot, view) registred as named adapters | 04:04 |
| projekt01 | Yes, nested call other pagelets from a ZPT and this ZPT can call other pagelets | 04:04 |
| Arnia | And can each pagelet have its own view class? | 04:05 |
| projekt01 | Belive me I was looking at your concept and reimplement it again in z3 way | 04:05 |
| projekt01 | Yes | 04:05 |
| Arnia | I thought I wrote it in a Z3 way :p | 04:05 |
| * Arnia feels impugned ;) | 04:05 | |
| projekt01 | I improved the permission proxy use and other parts | 04:06 |
| Arnia | The permissions were the bits I could quite get... but I seem to have a mental block on the security system for some reason | 04:06 |
| projekt01 | Sessia checks the permission on attributes z3 pagelets are proxied | 04:06 |
| Arnia | May we have conditions on the Z3 pagelets then? | 04:07 |
| Arnia | (iirc it was fairly trivial to write... *checks*) | 04:07 |
| projekt01 | Should we add conditions on z3 paglets? | 04:08 |
| philiKON | +1 on pagelet conditions | 04:08 |
| projekt01 | I'm pretty sure if we provide the condition attribute in the directive I'm pretty sure your Sessia configure.zcml will work if you change it to browser:pagelet | 04:09 |
| Arnia | projekt01: Also, we need macro name specification | 04:10 |
| projekt01 | Arnia, can you try to use some Sessia configure.zcml and siwthc to browser:pagelet without use the condition? | 04:10 |
| Arnia | projekt01: So that people can build full page templates in Dreamweaver say and mark out their pagelets using macros and still call them | 04:11 |
| projekt01 | That's the same you can also use inline code in the ZPT | 04:12 |
| projekt01 | See: | 04:12 |
| projekt01 | <metal:block tal:repeat="pagelets pagelets:zope.app.boston.slots.IJavaScript"> | 04:12 |
| projekt01 | <tal:block metal:use-macro="pagelets" /> | 04:12 |
| projekt01 | </metal:block> | 04:12 |
| Arnia | projekt01: How does the pagelet directive select for a particular macro in the file? | 04:12 |
| philiKON | Arnia, what do you mean by macro name spec? please, no naming convention or anything | 04:12 |
| Arnia | philiKON: I mean the ability to say "I want to take my pagelet from this macro in this template file" | 04:13 |
| philiKON | that should be in the browser:pagelet directive | 04:13 |
| Arnia | philiKON: It is in the Siesia one... not (afaict) in the zope one | 04:13 |
| projekt01 | Pagelets are named multi adapters, the name is the name of the macro in the ZPT | 04:13 |
| Arnia | Really? Oh... ok | 04:13 |
| philiKON | <browser:pagelet .... template="foobar.pt" macro="bar" /> | 04:14 |
| Arnia | Seems a bit... magic to me... dunno though. Is that accepted practice? | 04:14 |
| philiKON | ah, cool | 04:14 |
| philiKON | it makes a lot of sense | 04:14 |
| Arnia | (name doesn't seem the right word to use... I wouldn't have understood that personally...) | 04:14 |
| eaon | projekt01: having a condition on a pagelet and having a condition in the zpt, is quite different... most of the time such conditions will be used for administration use, and not development one, so editing the code for this is not the way it should be done (as it is able to break easily on upgrades - we had a lot of that in plone) | 04:14 |
| philiKON | Arnia, that usage of named adapters is very z3ish though | 04:15 |
| philiKON | Arnia, don't see it as a macro name | 04:15 |
| projekt01 | Arnia, then call <span tal:content="pagelet:aInterface/name" /> | 04:15 |
| philiKON | Arnia, see it as an id of that particular IJavaScript pagelet | 04:16 |
| Arnia | projekt01: Uh... but you might have several pagelets in a single template, all with different macros... how would you render them all? | 04:16 |
| projekt01 | eaon, I'm not against using condition in pagelets directive. I think there is to much configuration. I like to register pagelets on the right component instead of using conditions | 04:16 |
| projekt01 | eaon, can you give me a sample for conditions? | 04:16 |
| philiKON | projekt01, sometimes conditions aren't component-driven | 04:17 |
| philiKON | projekt01, but maybe user or request driven | 04:17 |
| Arnia | projekt01: sometimes they depend on a single field from the context object | 04:17 |
| projekt01 | philiKON, register the pagelets for this component or even a single view like a edit view of the ocmponent. This is not a usecase for conditions | 04:17 |
| projekt01 | Arnia, That's exactly what we don't like to use in ZCML | 04:18 |
| projekt01 | ZCML is not a scripting language!!! | 04:18 |
| philiKON | right | 04:18 |
| philiKON | but it's the wiring | 04:18 |
| philiKON | and this is part of the wiring | 04:18 |
| philiKON | it defines how the wiring is supposed to happen | 04:18 |
| Arnia | projekt01: What if the existence of a pagelet in a particular rendering of a particular deployment (and this is a deployment scenario) depends on something in the request (an error message say) | 04:19 |
| philiKON | projekt01, yes it is; take this condition, for example: request.locale.id == 'en' | 04:19 |
| projekt01 | If you say thats wirring, why do we not have conditions in edit views or all directives, why should a edit view not define field constraints in ZCML? | 04:20 |
| projekt01 | Remeber pagelets are just views. | 04:21 |
| Arnia | I'm seriously considering that actually | 04:21 |
| projekt01 | Views do not have such conditions in ZCML | 04:21 |
| philiKON | you're right | 04:21 |
| Arnia | Because it is just wiring... important wiring at that | 04:21 |
| philiKON | adapters are just looked up | 04:21 |
| projekt01 | This has to be handeld in the view class | 04:21 |
| philiKON | so, either we need conditional adapter lookup (for all adapters) or we dont' have conditions for pagelets | 04:22 |
| projekt01 | You can return a pagelet, ubut this means not the the pagelet shows something if the condition doesnt fit | 04:22 |
| Arnia | projekt01: conditions are important as they're usually a deployment issue. Hence why they should be definable in ZCML | 04:22 |
| Arnia | Otherwise everyone has to subclass for deployment | 04:22 |
| projekt01 | philiKON, yes you proposing this for pagelet (multi adpater) | 04:22 |
| Arnia | Which is not a great demonstration of reuse really | 04:22 |
| projekt01 | Adapters are normaly registred on one interface, views a re muti adapter where we can use the request which we can use for layers/skins | 04:23 |
| philiKON | so, on one hand we have Arnia who is use-case driven; his argument is that it's deployment-driven... whcih is very true | 04:23 |
| philiKON | on the other hand, pagelets are just adapters | 04:23 |
| projekt01 | Pagelets include also views and slot interfaces | 04:23 |
| philiKON | a very pure concept | 04:23 |
| projekt01 | If we use conditions I think we get a "do it all in one solution" | 04:24 |
| philiKON | projekt01, btw, right now, we're always assuming that pagelets are ZPT macros, right? | 04:24 |
| Arnia | philiKON: Shouldn't do really... pagelets may be used in binary or non-XML generation | 04:25 |
| philiKON | yep | 04:25 |
| philiKON | although... those could be different multi-adapters | 04:25 |
| Arnia | philiKON: It would be nice to reuse the modularity of view construction if we can though | 04:26 |
| projekt01 | If we have conditions, pagelets can do everything | 04:26 |
| philiKON | we could, by definition, say that a "pagelet" is always a multi-adapter that returns a page template macro | 04:26 |
| philiKON | Arnia, view construction is up to your app | 04:26 |
| philiKON | not pagelets | 04:26 |
| projekt01 | Yes, that's correct | 04:26 |
| philiKON | projekt01, what do you mean by "can do everything"? | 04:26 |
| Arnia | philiKON: view construction is up to whatever machinery is used by the app... no need to force people to reinvent the wheel all the time | 04:27 |
| philiKON | well, for binary representation, view construction is what... concatenation? | 04:27 |
| philiKON | the only big wheel we have is lookup, and thanks to adapters that is handled by the adapter service (now site manager) | 04:27 |
| Arnia | philiKON: For non-binary non-XML we still need a modular way to include content | 04:28 |
| Arnia | (into the render) | 04:28 |
| projekt01 | A adapter is somthing like to get a python instance if you give the right (provided) components adapting this components. You also can instance dummy components providing the right interfaces and give them for calling getMultiAdapter. If we do this you can do everything | 04:28 |
| philiKON | Arnia, yes, but that's a) yagni for now and b) depends on the scripting language (DTML or whatever) used and c) is probably out of scope of zope.app.pagelet | 04:29 |
| philiKON | projekt01, i know all this, but i don't understand your statement about being able to do everything | 04:29 |
| Arnia | philiKON: I disagree... I need it to generate Notation3 renders for a project I'm working on. I'd like to use pagelets to do this since they're the same concept just I'm doing it without an XML format | 04:30 |
| philiKON | Arnia, but with XHTML/XML, we obviously want to use pagetemplates | 04:30 |
| projekt01 | If you have a context, view and request, you only have to use the right slot and call a named pagelet. What you do with the pagelet (which is only a python instance) is up to you. | 04:31 |
| philiKON | so, with XHTML/XML that serves as our "pagelet construction kit" | 04:31 |
| philiKON | whatever you use for your NOtation3 as a dynamic engine for content generation will have to look up named multi adapters | 04:32 |
| philiKON | it's that simple | 04:32 |
| philiKON | call them pagelets or not | 04:32 |
| Arnia | philiKON: Yes... but I think pagelets are more general as a concept than just XML. So I'd like to avoid restricting ourselves for no good reason. Not asking for a complete implementation of non-XML, just not restricting ourselves apriori. Is that ok? | 04:32 |
| Arnia | :) | 04:32 |
| * tvon wishes irc was threaded | 04:32 | |
| philiKON | yes, that's ok | 04:32 |
| philiKON | but, we should also keep the focus of zope.app.pagelet in mind | 04:32 |
| Arnia | philiKON: I just separated the general composition stuff from the specific TemplatePagelet version | 04:33 |
| Arnia | philiKON: I think that's a good principal to follow... who knows what wacky applications of the composition machinery future developers may dream up | 04:33 |
| philiKON | take this exmaple from the boston skin: | 04:34 |
| philiKON | <metal:block tal:repeat="pagelets pagelets:zope.app.boston.slots.ICSS"> | 04:34 |
| philiKON | <tal:block metal:use-macro="pagelets" /> | 04:34 |
| philiKON | </metal:block> | 04:34 |
| philiKON | here, we assume that whatever is looked up as a pagelet is a zpt macro... | 04:34 |
| Arnia | philiKON: Regions are based on a particular collection of pagelets though | 04:34 |
| philiKON | so, you mean that all ICSS pagelets can be assumed to be zpt macros? | 04:35 |
| Arnia | But I take your point | 04:35 |
| projekt01 | Arnia, pagelets can be called form python views and return code from the pagelet instance without to us a ZPT | 04:35 |
| Arnia | projekt01: Sorry... I didn't follow that. Could you rephrase? | 04:35 |
| projekt01 | You can implement a pagelet which returns not macro code, perhaps we have to call it xmlpagelet | 04:36 |
| philiKON | it might be a good rule to have pagelets that are used in ZPTs adapt to an interface that inherits IZPTPagelet or something | 04:36 |
| projekt01 | Then you can handle xml | 04:36 |
| projekt01 | And use it somewhere | 04:36 |
| projekt01 | PhiiliKON, yes | 04:36 |
| philiKON | so, in the above example, ICSS would inherit from IZPTPagelet | 04:36 |
| Arnia | philiKON: I meant its a sensible assumption, but since pagelets are mapped to regions by deployment its not entirely sensible. But if we did it like you suggested then I think that would work. | 04:37 |
| philiKON | so that we explicitly can expect from that pagelet to be a zpt macro | 04:37 |
| Arnia | ICSS is a region is it not? | 04:37 |
| projekt01 | I think it does smothing like that | 04:37 |
| philiKON | i guess it denotes that | 04:37 |
| projekt01 | Arnia, Yes | 04:37 |
| philiKON | ah, i just found IPageSlot | 04:38 |
| philiKON | IPageletSlot | 04:38 |
| projekt01 | I think a region is in Sessia a string in z3 it is a interface or a dotted name of the interface. This makes it better follow whats happen | 04:38 |
| projekt01 | philiKON, Yes | 04:38 |
| Arnia | projekt01: I'd also like to explain why I chose the term 'region' rather than reusing the term 'slot' (it wasn't just caprice on my part)... basically, I don't think pagelets and portlets should be managed together | 04:38 |
| Arnia | projekt01: Its an interface in Siesia | 04:38 |
| Arnia | Deliberately so | 04:38 |
| philiKON | interfaces rock :) | 04:39 |
| philiKON | Arnia, also, slot is more of a zpt term | 04:39 |
| * philiKON likes region | 04:39 | |
| projekt01 | Ah, ok | 04:39 |
| Arnia | philiKON: Yes | 04:39 |
| philiKON | region is very descriptive | 04:40 |
| philiKON | a region really is an interface | 04:40 |
| philiKON | a slot is just some structure in a zpt macro | 04:40 |
| projekt01 | I think slots are a common term for to tell everybody that something is inserted. Python use slots too in modules. | 04:40 |
| projekt01 | I think slots are also use in the TAL engine for macros. But I'm not sure. | 04:41 |
| *** tvon|desk has joined #zope3-dev | 04:41 | |
| philiKON | a pagelet adapts (context, request) to the region | 04:41 |
| projekt01 | This slots get filled with other content form a macro | 04:41 |
| philiKON | projekt01, right | 04:41 |
| philiKON | anyway, we should probably use the word region and come up with a well-defined nomenclature for pagelets | 04:42 |
| * philiKON is very sensitive about nomenclature after having written a book | 04:42 | |
| philiKON | only the condition issue remaining | 04:42 |
| Arnia | philiKON: I wrote a lot in my documentation | 04:42 |
| projekt01 | Arnia, does the Sessia pagelet only adapt (context, request)? | 04:43 |
| Arnia | philiKON: I'm quite sensitive to defining terms | 04:43 |
| Arnia | projekt01: No... context, request, view, region | 04:43 |
| * Arnia goes to check that | 04:43 | |
| projekt01 | Arnia, I was thinking so | 04:43 |
| philiKON | what are zope.app.pagelet pagelets? | 04:44 |
| philiKON | (context, request, view) => region? | 04:44 |
| Arnia | projekt01: I don't adapt request... but I was going to | 04:44 |
| Arnia | In mine I adapt to IPagelet | 04:44 |
| *** `anthony has quit IRC | 04:44 | |
| philiKON | adapting to the region seems more elegant | 04:44 |
| Arnia | Does a 'weight' make any sense on a region? | 04:45 |
| philiKON | weight? | 04:45 |
| projekt01 | The directive for z3 pagelets uses the following registration: | 04:45 |
| projekt01 | args = ('provideAdapter', (for_, layer, view, slot), IPagelet, name, new_class, _context.info),) | 04:45 |
| Arnia | I'd argue that adapting to the region means putting nonsense information on interfaces (from a human point of view) | 04:46 |
| philiKON | projekt01, mmh, so you also adapt to IPagelet | 04:46 |
| philiKON | projekt01, why not adapt to slot? | 04:46 |
| philiKON | Arnia, huh? | 04:46 |
| Arnia | philiKON: IPagelet includes information about weights, conditions etc | 04:46 |
| Arnia | philiKON: Why would that be relevant to a IPageRegion? | 04:47 |
| philiKON | well, here's why i don't like adapting (for, layer, view, slot) | 04:47 |
| philiKON | for is my context object | 04:47 |
| philiKON | layer is the request | 04:47 |
| philiKON | view the view objegct | 04:48 |
| philiKON | but what objecdt represents the region (or slot here) | 04:48 |
| philiKON | slot is just an interface | 04:48 |
| philiKON | a region is represented by an interface, not by an object | 04:48 |
| philiKON | so, either we are adapting interfaces, or dummy objects | 04:48 |
| philiKON | to me it sounds cleaner adapting to the region | 04:48 |
| philiKON | and from an architectural point of view: | 04:49 |
| projekt01 | But you get a pagelet and the pagelet don't provide the IRegion interface | 04:49 |
| Arnia | philiKON: it wouldn't be IPageRegion then... it would be IRegionPagelet | 04:49 |
| philiKON | IRegion would be a marker interface subclassing IPagelet | 04:49 |
| philiKON | Arnia, right | 04:49 |
| philiKON | class ICSS(IPagelet): | 04:50 |
| Arnia | Also means you could restrict all pagelets in a region to be of a particular sort | 04:50 |
| philiKON | projekt01, i don't like slot being a dummy Wrapper() instance right now | 04:51 |
| projekt01 | philiKON, you proposing that the slot is obsolete, hm. Let's think about it..... | 04:51 |
| philiKON | projekt01, creating an object just for the sake of adaption soundsn bogus | 04:51 |
| philiKON | adaption should always be meaningful | 04:51 |
| Arnia | No, not that slots are obselete... just that they're represented differently | 04:51 |
| philiKON | (context_object, request, view) ====adapt===> slot/region | 04:52 |
| philiKON | note that we right now have an analogy with views: | 04:52 |
| philiKON | (context_object, request) ===adapt===> IBrowserPublisher (if a view wants to be published through zope.publisher to a browser) | 04:52 |
| Arnia | Hah... IBrowserPublisher as a region ;) | 04:53 |
| philiKON | if you want :) | 04:53 |
| projekt01 | philiKON, Ok I see, let's find it out if this works.... Not a bad idea. But perhaps there are other reason for not doing this | 04:53 |
| Arnia | I like it the more I think about it | 04:53 |
| philiKON | projekt01, i will formally propose this next week in a proposal | 04:53 |
| philiKON | that should give us all time to think about it | 04:53 |
| projekt01 | I just don't know right now, but is sound good | 04:53 |
| Arnia | Would be interesting to see if widgets could be treated as pagelets | 04:53 |
| philiKON | in the end, i want EVERYTHING to be a pagelet | 04:54 |
| philiKON | even the contents.html view | 04:54 |
| philiKON | so that i can reuse it | 04:54 |
| Arnia | (to allow form generation to pull stuff from orthogonal interfaces) | 04:54 |
| philiKON | yeah, editforms should be pagelets too | 04:54 |
| projekt01 | philiKON, Arnia, I like every improvements on pagelets | 04:54 |
| Arnia | Each generated form could be a new region | 04:54 |
| projekt01 | +1 | 04:54 |
| Arnia | With pagelets registered for each widget | 04:54 |
| philiKON | that's an interesting approach | 04:55 |
| * philiKON likes | 04:55 | |
| Arnia | So the whole generation machinery becomes just pagelet look up | 04:55 |
| philiKON | we should write these up into proposal | 04:55 |
| philiKON | so gary knows what's coming at him for 3.2 form wrap up :) | 04:55 |
| philiKON | anyway, nice talking to you tonight | 04:55 |
| Arnia | Yeah... who should write it? | 04:55 |
| philiKON | i'm really really going to bed now *grin* | 04:55 |
| projekt01 | Arnia, javascripts used in special widgets, that's was the reason I started moving Sessia pagelets to z3 | 04:56 |
| *** `anthony has joined #zope3-dev | 04:56 | |
| philiKON | Arnia, well, we first need to get 3.1 out of the door before we touch anythign that is going to be released in 3.1 | 04:56 |
| Arnia | projekt01: My interest in using pagelets for forms stems from allowing me to improve the markup of widgets easily or allow new renders to be dropped in | 04:56 |
| Arnia | PDF forms for example... | 04:56 |
| philiKON | Arnia, zope.app.pagelet is not in 3.1 so we can start messing with it now | 04:56 |
| Arnia | philiKON: Ok, cool | 04:56 |
| philiKON | but the formal proposal process for a zope.app.form revamp (e.g. pagelets) could start now | 04:57 |
| projekt01 | Please drop me a note if you refactoring pagelets, it has not to be backward compatible, but we use it in productive projects | 04:57 |
| philiKON | anyway, let's think about the adaption (and condition) thing for a couple of nights and finish that discussion nextw eek | 04:57 |
| Arnia | philiKON: Ok, sure | 04:58 |
| philiKON | projekt01, of course. from me you'll always hear in form of a proposal (or at least an RFC to zope3-dev) | 04:58 |
| Arnia | I may begin hacking on ideas now though... just to test some stuff | 04:58 |
| Arnia | (on my own system of course) | 04:58 |
| philiKON | g'night | 04:58 |
| projekt01 | I think migration isn't a problem because it's nothing persitent | 04:58 |
| *** philiKON is now known as philiZZZ | 04:58 | |
| Arnia | night | 04:58 |
| eaon | sleep well | 04:58 |
| projekt01 | PhiliKON, good night | 04:58 |
| projekt01 | Arnia, are you interested to work on z3 pagelets after the 3.1 release? | 04:59 |
| projekt01 | Arnia, perhaps you can take a look at zope.app.pagelet.README.txt There is the abstraction described where we have done | 05:00 |
| *** projekt01 has left #zope3-dev | 05:03 | |
| *** BjornT has quit IRC | 05:17 | |
| *** hazmat has quit IRC | 05:55 | |
| *** RaFromBRC is now known as RaFromBRC|out | 06:27 | |
| *** ignas has joined #zope3-dev | 06:41 | |
| *** hazmat has joined #zope3-dev | 06:44 | |
| *** `anthony has quit IRC | 07:41 | |
| *** viyyer has joined #zope3-dev | 08:05 | |
| *** th1a has quit IRC | 08:43 | |
| *** hazmat has quit IRC | 08:44 | |
| *** ignas has quit IRC | 08:45 | |
| *** hazmat has joined #zope3-dev | 08:53 | |
| *** `anthony has joined #zope3-dev | 08:54 | |
| *** sashav has joined #zope3-dev | 09:32 | |
| *** Theuni has joined #zope3-dev | 09:38 | |
| zagy | moin | 09:43 |
| AJC | what's the easiest way to get a new plain ReST page? | 10:13 |
| Theuni | maybe touch "file.rst" | 10:15 |
| Theuni | ? | 10:15 |
| AJC | nah, i mean within the Zope3 hierarchy itself | 10:16 |
| AJC | is there an object that does this for me or do i need to code up a simple page? | 10:17 |
| * Theuni shuts up | 10:21 | |
| *** admp has joined #zope3-dev | 10:23 | |
| *** vlado|away has quit IRC | 10:28 | |
| *** vlado|away has joined #zope3-dev | 10:29 | |
| *** Jim7J1AJH has quit IRC | 10:30 | |
| *** Jim7J1AJH has joined #zope3-dev | 10:32 | |
| *** vlado|away is now known as vlado | 10:45 | |
| *** projekt01 has joined #zope3-dev | 11:10 | |
| *** admp has joined #zope3-dev | 11:11 | |
| *** MrTopf has joined #zope3-dev | 11:27 | |
| MrTopf | hi | 11:27 |
| Arnia | Hi | 11:27 |
| projekt01 | srichter, ayt | 11:32 |
| Arnia | projekt01: heya | 11:32 |
| projekt01 | hi | 11:32 |
| projekt01 | Arnia, do you have productive z3 projects in development? | 11:33 |
| Arnia | You mean client deployments? | 11:34 |
| projekt01 | Yes | 11:34 |
| Arnia | Not at this time, no. Although I may do in a month | 11:34 |
| Arnia | (negotiating atm) | 11:34 |
| projekt01 | Cool | 11:34 |
| Arnia | I want to move the NN site across to Z3 asap anyway for various reasons | 11:35 |
| Arnia | So if our internal site counts as a deployment ;) | 11:35 |
| projekt01 | of corse | 11:35 |
| *** philiZZZ is now known as philiKON | 11:36 | |
| Arnia | I have been looking over your z.a.pageletchooser stuff | 11:36 |
| philiKON | moin guys | 11:36 |
| projekt01 | hi | 11:36 |
| AJC | hey | 11:36 |
| Arnia | I was wondering about how the pagelet names render in the interface | 11:36 |
| AJC | is the zope3-dev list administered? | 11:36 |
| Arnia | Hey philiKON | 11:36 |
| philiKON | AJC, no, but you need to be subscribed to post | 11:37 |
| projekt01 | Arnia, it's just a example of one way do choose pagelets, there are many other possible ways to do this | 11:37 |
| philiKON | AJC, as for this rest page, you need to code it yourself; i have a very basic implementation for my worldcookery.com site, see wcsite-1.0.tar.gz on http://worldcookery.com/Downlaods | 11:37 |
| AJC | philiKON: hmmm, i think i made the mistake of attaching my twisted script, which probably got filtered | 11:38 |
| AJC | philiKON, fantastic, thanks | 11:38 |
| Arnia | projekt01: Yes... but I'm always thinking of usability of deployed code ;) | 11:38 |
| philiKON | AJC, i see your post with the attachment | 11:38 |
| projekt01 | Arnia, you are right, perhaps we can improve it for 3.2 | 11:38 |
| Arnia | projekt01: I was wondering whether a general way to give longer titles and descriptions to interfaces may be good | 11:39 |
| Arnia | projekt01: s/interfaces/interfaces, classes and adapters/ | 11:39 |
| Arnia | projekt01: Maybe apidoc has a way to extract stuff from docstrings? | 11:39 |
| projekt01 | Hm, I don't understand this | 11:40 |
| projekt01 | What do you mean with longer titles? | 11:40 |
| projekt01 | In pageletchooser? | 11:40 |
| projekt01 | Or use the interface as key in ZPT? | 11:40 |
| projekt01 | Interface = dotted name of the interface | 11:41 |
| Arnia | In chooser... and in palette style selections (if we go for 'draggable' page design) | 11:41 |
| Arnia | So people know what these strings of characters are | 11:41 |
| projekt01 | Ah, you mean if we drag a pagelet from one slot (region) to another | 11:42 |
| projekt01 | And then we have to show a meaningful name | 11:42 |
| Arnia | Well... it doesn't matter the precise interface but yes. We need human meaningful names | 11:42 |
| Arnia | I think this may be something that applies generally across components | 11:42 |
| projekt01 | Ok, this is where we need another pageletchosser | 11:43 |
| projekt01 | I worte some comments in the code | 11:43 |
| projekt01 | Perhphaps tat's a job for a layoutmanager | 11:43 |
| Arnia | Perhaps... something to consider for choosers | 11:43 |
| projekt01 | Yes, of corse | 11:44 |
| projekt01 | I use already another pageletchooser in our project | 11:44 |
| Arnia | projekt01: Also, we've already begun work on a best-practices style-guide as part of our HIG. Interested in looking it over? | 11:44 |
| Arnia | projekt01: Its based on our experiences with building the Plone markup and accompanying default CSS. As well as our experiences doing CSS-only customisations (such as on our website) | 11:45 |
| projekt01 | Yes, of corse, but in general I think it is sometimes a overhead. Most the time I just need some slots (region) for Javascript, CSS | 11:46 |
| AJC | congrats for the book philiKON | 11:46 |
| projekt01 | But you are right, for a general page layout it's cool to have a standard way. | 11:46 |
| philiKON | AJC, thanks | 11:46 |
| projekt01 | Like you say best-practice or recommended | 11:47 |
| Arnia | projekt01: How is it overhead to have a set of best-practices? Besides, one of the main goals we've had for Siesia was to make it so developers don't need to touch mark-up | 11:47 |
| Arnia | projekt01: We've seen first hand how those without the specialised skills involved tend to mess it up without realising. Creating an accessible, valid and lightweight UI is surprisingly hard. | 11:49 |
| projekt01 | If we recommend all regions like used in Sessia and I can just pick some of them, it's not a overhead. But if I have to use all of them and mose regions never get filled | 11:49 |
| Arnia | projekt01: Well that doesn't matter to a CSS-styled skin so much. Especially since we do an empty region check in LF I believe | 11:50 |
| projekt01 | Ok, sounds good | 11:50 |
| projekt01 | For me it was hard in the first time to see what I need and what is not needed. I think that's all the time one of the biggest problem not only with pagelets | 11:51 |
| projekt01 | In the first time I like to show what's a pagelet. And later we can make exesive use of them | 11:51 |
| Arnia | projekt01: We've spent about 8 months analysing the semantics of a view's regions and have come up with a good list of 'standard' regions. Not all sites need all of them... however shuffling pagelets should be a semantic shuffle, not done purely for graphic effect | 11:52 |
| projekt01 | But if you show a Sessia page to a new develeoper, he will quit an use something else. | 11:52 |
| Arnia | projekt01: But that's a requirement of accessibility (and I'm not becoming liable because of the DDA under any circumstances ;) | 11:53 |
| projekt01 | That's the reason that everybody is scarry about pagelets right now. It's to much at one time | 11:53 |
| Arnia | projekt01: If you show him all at once, yes he will run away. However you're not meant to touch most of siesia | 11:53 |
| projekt01 | Yes I understand, we don't have this much UI people here in z3. More or less nobody. | 11:53 |
| Arnia | projekt01: You're meant to build your own small chunks as and when you need them and know that most of the site is comfortably present anyway | 11:54 |
| *** lunati1 has joined #zope3-dev | 11:54 | |
| Arnia | projekt01: I'm again pushing for pure CSS design as much as possible simply because there is no better way to ensure accessibility. It helps that more and more designers are training on CSS as a first-step | 11:55 |
| projekt01 | If we like to integrate pagelets we have to be carfull and make sure everybody can follow. | 11:55 |
| philiKON | projekt01, we just need good documentation, that's all | 11:56 |
| projekt01 | Yes, but some important things are not possible with pure CSS | 11:56 |
| projekt01 | Yes, sure | 11:56 |
| Arnia | projekt01: Such as? | 11:56 |
| Arnia | projekt01: Reflowing of elements isn't possible in tables either... but is possible with pagelets in both | 11:56 |
| projekt01 | A left slot can dynamicly change the width | 11:57 |
| Arnia | projekt01: Yes, that can be done with CSS. | 11:57 |
| projekt01 | We don't reload the page everytime, we use also XMLHTTP requests, | 11:57 |
| projekt01 | No this can't be done in CSS | 11:57 |
| Arnia | Yes it can. I've done it | 11:57 |
| Arnia | You use a float | 11:58 |
| philiKON | projekt01, don't underestimate the power of CSS | 11:58 |
| *** MrTopf has quit IRC | 11:58 | |
| projekt01 | I know the power of CSS and I know also the bugs there | 11:58 |
| Arnia | projekt01: Tom, Mikey and I have hit virtually every bug under the sun whilst working on Plone. We've got good ties with various members of the browser teams and we have found workarounds for most of the showstoppers we found. | 11:59 |
| Arnia | projekt01: No, CSS can't do everything. But it can do more than tables, and it allows a structured markup. If you don't use structured markup you risk failing WCAG | 12:00 |
| projekt01 | I hate workarrounds for everything. if I can use the nice old table layout. Of corse if accessibiity is a requierment, then we have to use pure CSS. But pure CSS is not the only right thing. | 12:00 |
| projekt01 | But how many people can do this? | 12:00 |
| Arnia | Fail WCAG and you can be sued. Plain and simple. And it is enforced by various bodies (RNIB being one of the strictest) | 12:00 |
| Arnia | projekt01: We managed to get plone.css to zero workarounds in tableless layout | 12:01 |
| philiKON | projekt01, that's why it is so important we use pagelets everywhere, so that we can make a crappy table-based skin until some CSS genius comes and does the whole thing WCAG-compliant for us | 12:01 |
| projekt01 | I don't speak about everything. Sure, enduser skins have to use CSS. But not the ZMI. | 12:01 |
| Arnia | projekt01: Why not the ZMI? | 12:02 |
| philiKON | what *is* the zmi | 12:02 |
| Arnia | projekt01: Don't blind people edit content now? | 12:02 |
| Arnia | Manage sites etc | 12:02 |
| projekt01 | Where should it do? The last 2 years nobody has had the skills and the power to do it. And I just tell everybody don't do it if we not have the skills. | 12:03 |
| projekt01 | Of corse if you like to do it and support it, it whould be nice to have it. | 12:03 |
| Arnia | We are doing it | 12:03 |
| Arnia | That's why we're writing Siesia LF atm | 12:04 |
| projekt01 | But we used a CSS layout which was not working and that's not what I think we should have. | 12:04 |
| Arnia | It ain't ready yet, but its getting there very quickly | 12:04 |
| Arnia | projekt01: ? | 12:04 |
| philiKON | Arnia, just make sure it'll be re-contributable to z3 and everybody will be kissing your toes | 12:05 |
| Arnia | philiKON: We've been writing all our stuff under the ZPL so it can be transfered to core if desired | 12:05 |
| projekt01 | The sample where I saw some times ago in Sessia LF is defently a overhead for a Rotterdam replacement. | 12:05 |
| philiKON | Arnia, that's nice | 12:05 |
| Arnia | philiKON: We just prefer hacking on our own server when experimenting with our ideas so we don't mess up core in the process | 12:06 |
| Arnia | projekt01: Siesia... and it isn't designed as just a Rotterdam replacement. However the overhead is tiny. The markup is highly structured, yes... but its accessible and light too | 12:08 |
| Arnia | projekt01: And a business is just as likely to be sued if its employees aren't given accessible interfaces. So there is no excuse for lack of accessibility in any part of a user interface | 12:09 |
| projekt01 | What do you think? Can we use a small set for Rotterdam and a "all region" set for enduser skins? | 12:10 |
| *** mexiKON has joined #zope3-dev | 12:12 | |
| Arnia | projekt01: I don't see why there should be a difference. Look at the markup structure of LF. The regions don't add to the weight of the generated markup | 12:12 |
| *** philiKON has quit IRC | 12:13 | |
| Arnia | projekt01: Why is Rotterdam so special? | 12:13 |
| *** mexiKON is now known as philiKON | 12:13 | |
| projekt01 | Arnia, what do you mean with special? | 12:13 |
| Arnia | projekt01: Personally, if I were a business I'd want my staff entering information in on the same interface others view it... same branding. Boosts morale | 12:13 |
| Arnia | projekt01: You're special casing one skin... I don't understand your reasons for it | 12:14 |
| projekt01 | That's not the z3 concept, nobody think so. But I think this way too. | 12:14 |
| philiKON | projekt01, uh, *what* is not the z3 concept?!? | 12:14 |
| Arnia | Err... repeat please. | 12:14 |
| * Arnia is very lost | 12:15 | |
| projekt01 | Can you agree that we can use more then one skin for a application? | 12:15 |
| philiKON | sure, sometimes that's requested by the customer even; but many times you don't have to use more than one skin | 12:15 |
| Arnia | You can... whether you should or not depends on the case | 12:16 |
| Arnia | Usually you shouldn't to be honest | 12:16 |
| projekt01 | Can you agree that one skin uses "zmi_views and zmi_actions" and another skin "user_views und auser_actions" | 12:16 |
| Arnia | No, I can't | 12:16 |
| Arnia | Its dividing the user interface in two, which is bad anyway, and dividing it poorly at that | 12:16 |
| projekt01 | That's the last stand of the UI concept, every skin has it's own stuff. Not everything is workig out of the box. Because this restrict everything. | 12:17 |
| Arnia | Users don't sit entirely in one camp or another, they are on a continuum between the 'camps' | 12:17 |
| projekt01 | Let's explain it a little bit more... | 12:18 |
| Arnia | A single task could require them to use both skins, if you have two skins. It is unacceptable for the user interface to change so much in a task flow | 12:18 |
| projekt01 | If you use the wiki, and you use a own skin with "xy_views" theh you can register the pages to this xy_views. | 12:19 |
| projekt01 | Yes, but you have to register the pages or other stuff to the second UI. It's not working out of the box | 12:19 |
| Arnia | Well, I'm a bit fed up of the 'product' mentality that this is a part of that approach | 12:20 |
| projekt01 | Otherwise you propose everybody has to follow the Sessia region requierements | 12:20 |
| *** `anthony has quit IRC | 12:20 | |
| Arnia | Siesia not Sessia. And what do you mean by region requirements? | 12:21 |
| projekt01 | That's not nice. You allways can write own skins and register the components where they are used in the second skin | 12:21 |
| projekt01 | Ok | 12:21 |
| projekt01 | A region set like used in Siesia is only one way | 12:22 |
| Arnia | Only one way to do what? | 12:22 |
| projekt01 | A product, package, or let's say the views in this package can allways registred for other skins/layers with a different set of regions | 12:22 |
| projekt01 | Something like the Siesia regions are only a recommendation. But this does not mean without them there is no way to use a package/product | 12:23 |
| projekt01 | Of corse you have to register everything again | 12:24 |
| Arnia | Well... I'll put aside the fact that I think layers are fundamentally broken :p | 12:24 |
| projekt01 | No, why? | 12:24 |
| Arnia | Most of the 'UI bugs' in Plone 2 were actually caused by the layer system | 12:24 |
| Arnia | It implicitly hides stuff and that is plain broken | 12:24 |
| Arnia | People find it very difficult to keep track of all the layers in a complex user interface | 12:25 |
| Arnia | And the forget they've implicitly hidden something they shouldn't have done | 12:25 |
| Arnia | This is very very bad | 12:25 |
| philiKON | well, the way layers are used in the cmf effectively is quite broken | 12:25 |
| philiKON | a skin in the cmf consists of about 20 layers | 12:25 |
| philiKON | the amount of layers is proportional to the amount of addon products | 12:26 |
| projekt01 | There is no layer in a skin. The UI is the layer. | 12:26 |
| philiKON | because that's the only way addon products can register their views | 12:26 |
| Arnia | I think its a general problem with layers as a concept. I'm not entirely sure of the use-cases for layers in Zope3 | 12:26 |
| Arnia | projekt01: I want to shift to autogenerating almost every view | 12:26 |
| philiKON | Arnia, with pagelets, layers become less and less necessary | 12:27 |
| Arnia | projekt01: Once we've sorted out the forms, we can do that | 12:27 |
| philiKON | Arnia, we'll see how that concept evolves once we are more pagelet-centric | 12:27 |
| projekt01 | Cool | 12:27 |
| projekt01 | I think we start this after the 3.1 release | 12:27 |
| philiKON | projekt01, the current concept is: MySkin = [layer1, layer2, layer3] | 12:27 |
| projekt01 | First I like to integrate the nested menu and preferences | 12:28 |
| projekt01 | Arnia, I change my mind on this MYSkin = [mylayer] | 12:28 |
| Arnia | projekt01: So what is your problem with Siesia? A standard set of regions, yes... but you can add a new region easily (without touching the siesia base code) or remove a region by not registering anything into it | 12:28 |
| projekt01 | And register every needed component with layer="mylayer" | 12:28 |
| Arnia | projekt01: Siesia becomes a basic harness onto which accessible UIs can be elegently strung | 12:29 |
| Arnia | Components insert UI elements into appropriate regions (cross-cutting particular views) by using pagelets | 12:30 |
| Arnia | Component-specific views are generated by using pagelets (allowing a combination of automatic widget composition and hand crafted templates) | 12:31 |
| Arnia | If you want to change the skin, you just change the appropriate pagelets. Including those of the widgets | 12:31 |
| projekt01 | Yes, but you mean high level or let's say complex UI's. There is no need for most regions in a simply Website. | 12:32 |
| Arnia | However, the idea is to show that Siesia LF is so easy, straightforward and flexible that there are only a few cases (plus non-XHTML views) when you'll need to do this | 12:32 |
| Arnia | projekt01: Yes there is | 12:32 |
| Arnia | What is the top-bar if not a region? | 12:32 |
| Arnia | The bottom-bar | 12:32 |
| Arnia | Left or right secondary content? | 12:33 |
| projekt01 | Yes, of corse. But belive me not everybody is happy to have this as a standard. | 12:34 |
| Arnia | Every website has regions... the ones chosen for LF simply represent a semantic cross cut of design practice. | 12:34 |
| *** apoirier has joined #zope3-dev | 12:34 | |
| Arnia | Well, if they don't want to use LF they don't have to. That's part of the wonder of pagelets | 12:35 |
| projekt01 | I agree, but there is also a way without regions and pagelets! | 12:35 |
| projekt01 | The pagelet pattern is only additional for z3. It's not a base concept! | 12:35 |
| Arnia | And you could write a wordprocessor in assembly language | 12:35 |
| Arnia | Would you actually do it nowadays? | 12:35 |
| projekt01 | Of corse we can do this. But we don't speak about it is not working without it. | 12:36 |
| Arnia | You can't force people to follow a concept... I'm not suggesting we do. However if z.a.forms starts using pagelets then they ARE a base concept in the Zope 3 UI system | 12:36 |
| Arnia | And they solve so many issues that I don't see why they shouldn't be | 12:37 |
| Arnia | However, whatever your thoughts, I'm going to continue to build LF because it solves a great need for little cost. I think you over-estimate the markup overhead of a Siesia LF page. Mikey already uses it for his simple blog site | 12:38 |
| projekt01 | You propose that if somebody writes a page/view he has to follow the pagelet pattern as default in the core? Right? | 12:39 |
| Arnia | projekt01: From his point of view I doubt he'll notice any different tbh | 12:39 |
| Arnia | projekt01: From now I mean | 12:39 |
| projekt01 | I just tell, that it has to be optional to use region like "top-bar" | 12:40 |
| Arnia | projekt01: If he produces a completely hand-crafted view, then its just a whole pagelet at once... not complicated | 12:40 |
| Arnia | projekt01: If he wants to change the markup used in bits of the site, he just registers replacement pagelets within those regions using overrides | 12:41 |
| Arnia | projekt01: Again, not complicated. | 12:41 |
| Arnia | projekt01: Each region in LF is a pagelet itself... so it can be turned off easily | 12:41 |
| Arnia | projekt01: And cos its designed with CSS, this has quite an elegent effect on the design | 12:42 |
| projekt01 | You propose to change the all the pages/views in the core with pagelets, just because you need a additional UI concept. I think this has to be happen optional. | 12:42 |
| Arnia | btw, to see how nice the markup is -- http://aeim.niij.org/journal/ | 12:42 |
| projekt01 | Again I like to use such a pattern, but this is only a additional concept and not the default concept at all. | 12:42 |
| Arnia | projekt01: No, because the existing UI concept is broken. Pagelets are a simplification and generalisation of lots of different incoherent parts from Zope3 as it stands | 12:43 |
| Arnia | It *is* a core concept. It *is* something that should be default. | 12:43 |
| Arnia | The only thing pagelets really do is modularise what is currently a hardcoded, magic-filled, monolithic mess | 12:44 |
| Arnia | This is necessary to allow a proper use of the component architecture concept to build modularised applications | 12:45 |
| Arnia | IMO at least... but its what I've seen using Zope 3 | 12:46 |
| projekt01 | Yes, you are right | 12:46 |
| Arnia | So, its a core concept, a concept worthy of being the default. I mean skins will be *easier* to understand once expressed as pagelets | 12:48 |
| projekt01 | But we have to be very careful with adding dependency to regions/slots | 12:48 |
| Arnia | I don't see why you're so hung up about that. | 12:48 |
| Arnia | The regions used are flexible | 12:49 |
| projekt01 | It's nothing else then "standard_macros" right now. | 12:49 |
| Arnia | But standardisation on page segments is handy when allowing cross-cut functionality | 12:50 |
| Arnia | You need to know where you're putting stuff | 12:50 |
| projekt01 | Yes, we have dependency to macros now and this will switch to dependency to regions | 12:50 |
| *** `anthony has joined #zope3-dev | 12:51 | |
| Arnia | But when you're dealing with a modularised system you need to be more precise with your placements | 12:51 |
| Arnia | So you need a wider set of regions | 12:51 |
| projekt01 | I'm sure if we can write down this concept only in one A4 page, and the people can follow, we can implement this pattern | 12:52 |
| projekt01 | Otherwise it will be a additional UI concept. | 12:52 |
| *** `anthony has quit IRC | 12:53 | |
| Arnia | Like I said... we've argued and analysed over the regions we've picked and they represent *standard usage* of site design in the real world with enough flexibility for edge cases. Took us a long time to do that | 12:53 |
| Arnia | projekt01: I've already done that | 12:53 |
| projekt01 | Yes, but nobody could follow the document where you proposed a year ago. It's high level, we need a more easy to understand document. Do you have something like a proposal? | 12:54 |
| Arnia | I can get you one | 12:55 |
| projekt01 | Btw, it was a great document, but big skills where requiered for following what are the problems described in the doc | 12:55 |
| *** `anthony has joined #zope3-dev | 12:56 | |
| Arnia | Try this -- http://developer.etria.com/groups/isia-community/isia/siesia-schema/roadmap/2 | 12:57 |
| projekt01 | We really need a simply proposal and show the benefit of pagelets | 12:57 |
| projekt01 | Yes, it is simply. I like to see a proposal which describes only the benefit of use regions and include content for all objects in a page. Additional stuff like drag and drop or extensive skinning should left out right now. | 13:01 |
| projekt01 | Simply describe the use of additional javascript for a speical widget, I think that's the best reason to use pagelets. Then there is no way to do it right now. | 13:02 |
| Arnia | I disagree that's the best reason | 13:02 |
| Arnia | I feel the best reason is to allow reconfiguration of layouts per deployment | 13:03 |
| projekt01 | Of corse it's not the best reason, but it's a killer factor, because we can't do it right now without pagelets. | 13:03 |
| projekt01 | That could be the reason to implement pagelets as a default concept | 13:04 |
| projekt01 | Additional benefits are no reason for change the concept right now. | 13:04 |
| Arnia | You can't, per deployment, reconfigure a layout either | 13:05 |
| Arnia | And that is what people asked for most from Plone | 13:05 |
| Arnia | They did horrendous hacks to get around that limitation | 13:05 |
| Arnia | They broke large chunks of the infrastructure just to achieve it | 13:05 |
| Arnia | Only a couple of times have people asked for javascript on widgets | 13:05 |
| projekt01 | I can't understand that somebody can work with this "do everything" CMS | 13:06 |
| projekt01 | I stopped two years ago, because it was to much for me. I don't like this much hacks in software. | 13:07 |
| projekt01 | That's the reason to switched to Z3 | 13:08 |
| Arnia | I don't understand what you mean by "do everything"... this is just good architecture | 13:08 |
| Arnia | It *stops* people from hacking around and breaking stuff | 13:08 |
| projekt01 | I can't agree that Plone or CMF is good architecture, but perhaps that's only my view. | 13:09 |
| Arnia | I'm NOT saying Plone or CMF are good | 13:09 |
| Arnia | I'm saying the precise opposite | 13:09 |
| projekt01 | Ah, ok | 13:09 |
| Arnia | I'm saying that we had problems with Plone for certain reasons, lets fix the reasons | 13:10 |
| projekt01 | Yes | 13:10 |
| Arnia | And lets fix them in an elegant and non-hacky way | 13:10 |
| Arnia | Which is what I'm proposing | 13:10 |
| projekt01 | Pagelets can solve a big problem | 13:10 |
| Arnia | But I'm also telling you, from experience, what people want to be able to do. What they'll break their system to achieve if the system doesn't give them a way to do it | 13:10 |
| Arnia | And it isn't 'javascripts on widgets' | 13:11 |
| Arnia | Its 'deployment relayout' | 13:11 |
| Arnia | Its 'conditions on chunks' | 13:11 |
| Arnia | Those were the top two requests | 13:11 |
| projekt01 | Yes, absolutly | 13:11 |
| Arnia | Those were why I started developing pagelets in the first place | 13:11 |
| Arnia | They are impossible without pagelets | 13:11 |
| projekt01 | But we need a sample not only theory. | 13:12 |
| Arnia | Well... it isn't only theory | 13:13 |
| Arnia | Given that I've needed this on my business site | 13:13 |
| Arnia | Which I couldn't do with Plone without hacking some of the templates | 13:14 |
| projekt01 | I have to go, can we meet us next week on IRC and workout some documentation | 13:14 |
| Arnia | Sure | 13:14 |
| projekt01 | You are right, but I like to show more handy usecases | 13:14 |
| projekt01 | Where people easy can follow and understand | 13:15 |
| Arnia | I'll properly write some out... I had some somewhere sometime | 13:15 |
| Arnia | Just need to find them again | 13:15 |
| *** viyyer has quit IRC | 13:15 | |
| projekt01 | Pagelets will radically change things what we can never do without them | 13:15 |
| projekt01 | Cool, see you soon | 13:16 |
| projekt01 | At least after the 3.1 release | 13:16 |
| *** viyyer has joined #zope3-dev | 13:18 | |
| *** tarek_ has joined #zope3-dev | 13:21 | |
| *** mgedmin has joined #zope3-dev | 13:41 | |
| *** Arnia has left #zope3-dev | 13:47 | |
| AJC | philiKON, are you sure wcsite-1.0 has the ReST stuff? the .py files are minimal! | 13:52 |
| *** anguenot has joined #zope3-dev | 13:54 | |
| *** viyyer has quit IRC | 13:58 | |
| *** vlado_ has joined #zope3-dev | 14:00 | |
| *** viyyer has joined #zope3-dev | 14:03 | |
| *** J1m has joined #zope3-dev | 14:05 | |
| *** vlado has quit IRC | 14:15 | |
| *** ignas has joined #zope3-dev | 14:19 | |
| *** Aiste has joined #zope3-dev | 14:26 | |
| *** zagy has quit IRC | 14:27 | |
| *** viyyer has quit IRC | 14:32 | |
| *** viyyer has joined #zope3-dev | 14:33 | |
| *** gintas has joined #zope3-dev | 14:42 | |
| *** viyyer has quit IRC | 14:45 | |
| *** viyyer has joined #zope3-dev | 14:45 | |
| *** Aiste has quit IRC | 15:03 | |
| *** Aiste has joined #zope3-dev | 15:07 | |
| *** srichter has quit IRC | 15:14 | |
| *** efge has joined #zope3-dev | 15:24 | |
| *** bskahan has joined #zope3-dev | 15:25 | |
| *** J1m has quit IRC | 15:29 | |
| *** lunati1 is now known as lunatik | 15:29 | |
| *** alga has joined #zope3-dev | 15:36 | |
| *** SteveA has quit IRC | 15:37 | |
| *** zagy has joined #zope3-dev | 15:50 | |
| *** [apoirier] has joined #zope3-dev | 15:57 | |
| *** apoirier has quit IRC | 15:59 | |
| *** srichter has joined #zope3-dev | 16:00 | |
| *** ChanServ sets mode: +o srichter | 16:00 | |
| *** palmTree has joined #zope3-dev | 16:04 | |
| *** niemeyer has joined #zope3-dev | 16:06 | |
| *** viyyer has quit IRC | 16:15 | |
| *** SteveA has joined #zope3-dev | 16:15 | |
| *** viyyer has joined #zope3-dev | 16:15 | |
| philiKON | AJC, yes | 16:16 |
| philiKON | AJC, z3 has builtin rest rendering support | 16:16 |
| philiKON | AJC, wcsite.page merely uses that | 16:16 |
| AJC | wow, that's very cool... thanks! | 16:17 |
| AJC | does your book cover such things? | 16:17 |
| philiKON | AJC, yes | 16:17 |
| AJC | great | 16:18 |
| * AJC scouts to Amazon | 16:19 | |
| AJC | *scoot* i guess | 16:19 |
| philiKON | AJC, problem is the shipping and U.S. customs; it'll take a week or two till it'll be available in the U.S. | 16:20 |
| AJC | i'm in Europe | 16:22 |
| philiKON | ah, that's better :) | 16:22 |
| AJC | not far from you i'm guessing | 16:22 |
| AJC | in Wien atm | 16:23 |
| philiKON | nice | 16:23 |
| AJC | do you know what's due in Zope X3.1? | 16:24 |
| philiKON | biggest changes are a refactoring of the comopnent architecture (no services anymore, everything, meaning utilities and adapters, is managed by the site manager), and the new pluggable authenticatin utility (PAU) to replace pluggableauth | 16:25 |
| AJC | ah, cool. | 16:27 |
| srichter | AJC: Read about the new features in CHANGES.txt | 16:27 |
| AJC | from SVN? | 16:27 |
| philiKON | yeah | 16:27 |
| philiKON | http://svn.zope.org/Zope3/trunk/doc/CHANGES.txt | 16:27 |
| srichter | there are some smaller but very useful new features: cleanup of apidoc (including support for 3rd party code), generic forms, menu reimplementation | 16:27 |
| * mgedmin reads last night's IRC logs and likes Arnia's thoughts on pagelets and clean portable CSS layouts | 16:30 | |
| *** palmTree has quit IRC | 16:42 | |
| mgedmin | one of these days I have to figure out just what a portlet is | 16:45 |
| eaon | oh, let me explain | 16:45 |
| eaon | i just woke up so it might be a little whacky though :) | 16:45 |
| projekt01 | mgedmin, see zope.app.pagelet.README.txt there is described what we have done | 16:46 |
| projekt01 | eaon, can you agree on this document? | 16:46 |
| projekt01 | The names are viewlet, pagelet and portlet | 16:46 |
| eaon | a portlet is a piece of a page that hasn't got a specific relation or function in relation to the portal, object or view | 16:47 |
| eaon | it's a piece of assistive technology or information, without direct boundness to portal/object/view | 16:47 |
| eaon | i haven't read it yet | 16:48 |
| eaon | let me see | 16:48 |
| eaon | the distinction between pagelet and portlet is very clear for us | 16:49 |
| projekt01 | Yes, but only for "us" | 16:49 |
| eaon | okay, let me try to explain | 16:50 |
| projekt01 | That's a bigger problem nobody understand exactly what it should be. | 16:50 |
| projekt01 | I think we need some papers not just a IRC chat | 16:50 |
| eaon | we're currently migrating the documentation we have, to work more on it | 16:51 |
| * mgedmin fixing typos in that README | 16:51 | |
| projekt01 | mgedmin, Thanks | 16:51 |
| eaon | http://zope.niij.org/nn-isia-dev/WDGTerminology | 16:52 |
| philiKON | yeah, there are a couple :) | 16:52 |
| projekt01 | You know.... | 16:52 |
| bskahan | eaon: there's a typo in the "Regions" section of that document | 16:53 |
| *** palmTree has joined #zope3-dev | 16:55 | |
| srichter | eaon: if you want your terminology to be accepted by the Zope 3 core team, you need to move the docs to the Zope repository or at least to the Zope 3 development Wiki | 16:55 |
| eaon | bskahan: where? can't find it ;) | 16:55 |
| bskahan | A region is a with pagelets fillable area. | 16:56 |
| eaon | okay - where's the typo? :D | 16:59 |
| eaon | srichter: makes sense, we're not z3 core yet though, thats why we "kept" docs in our own wiki | 17:00 |
| srichter | well, but you need to define and analyze the problem domain and tell us how the new concepts address the problems/issues | 17:01 |
| srichter | and that is done with documentation in the proposals section | 17:01 |
| srichter | this way we can react and make suggestions | 17:01 |
| eaon | yeah, i'll make us beat eachother to do that :) | 17:01 |
| srichter | and then we start together working on an implementation (in this case adjusting the checked in code) | 17:02 |
| mgedmin | eaon, I suspect an Englishman would say "A region is an area fillable with pagelets", but I am not one | 17:02 |
| eaon | mgedmin: thanks ;) | 17:03 |
| * mgedmin waits for bskahan to say "actually, that's not what I meant: ..." | 17:03 | |
| projekt01 | mgedmin, is the README understandable? | 17:03 |
| bskahan | mgedmin: it is :) | 17:03 |
| mgedmin | projekt01, I understand the difference between portlets and pagelets now | 17:06 |
| projekt01 | Cool | 17:07 |
| eaon | a pagelet may be used, for example, to assemble special actions with regards to the object (adding a workflow-changing form to the object editing actions), whereas a portlet is part of the website that you usually get on each sides, so basically, a navtree/other navigation, calendar, news announcments, etc | 17:10 |
| eaon | so a pagelet is much more flexible than a portlet | 17:10 |
| eaon | do i make sense? ;) | 17:12 |
| efge | Jean-Marc Orliaguet has been busy implementing his portlet system for Z3 | 17:13 |
| efge | but it's in the paris-sprint repository and I think ZC still hasn't made it visible... | 17:13 |
| projekt01 | efge, it looks very cool (he point me to a link). I like to see the code.... | 17:15 |
| *** bradb has quit IRC | 17:15 | |
| srichter | efge: projekt01: eaon: wow, there are so many people with ideas and there is already a split; we have three portlet/pagelet systems! Was this not something we wanted to avoid in Zope 3? | 17:17 |
| projekt01 | eaon, we have two different parts (you can call this pagelets or portlets or whatever). One part uses page template macros as the output and one part uses python views methods (python views can include ZPT by itself) | 17:18 |
| projekt01 | srichter, I think what we have in z3 now is a abstract implementation of all of them. | 17:18 |
| srichter | I think the problem is that noone is taking the time to write up an analysis of the problem, so we can all discuss it and work on a extendable version together that can be put in the core | 17:18 |
| projekt01 | I'm sure eaon will find all what he needs there. | 17:18 |
| *** sashav has quit IRC | 17:19 | |
| philiKON | srichter, i don't think we wanted to avoid a manifold landscape of different implementation | 17:19 |
| srichter | projekt01: we still need this analysis document, so people not having thought about the problem domain can have an entry point | 17:19 |
| philiKON | srichter, with z3 we just wanted to make sure they can interoperate by well-defined contracts | 17:20 |
| projekt01 | Pagelets are multiadapter and rreturn ZPPT maco code, pagedata is a adapter which will return a pythin instance adapting all what we need. | 17:20 |
| philiKON | srichter, do i need to update CHANGES.txt for my zope.pulbisher fix? | 17:20 |
| srichter | philiKON: exactely! and this is a reason we need to analyze the problem domain, so that we can agree on an initial set of cotnracts | 17:21 |
| srichter | philiKON: yeah, it's a bug fix | 17:21 |
| philiKON | was 'fraid you'd say that | 17:21 |
| srichter | philiKON: :-) | 17:21 |
| philiKON | btw, we should convert all docs to reST | 17:21 |
| srichter | philiKON: I usually just copy my checkin message | 17:21 |
| philiKON | i exceedingly hate STX | 17:21 |
| srichter | philiKON: most docs are converted | 17:22 |
| projekt01 | srichter, yes it's only a matter of naming and documenting. If somebody can show a good document, I can explain where to find the relevant parts in zope.app.pagelet | 17:22 |
| philiKON | changes.txt isn't | 17:22 |
| srichter | philiKON: I tried hard since X3.0 to use ReST | 17:22 |
| srichter | the old entries are not of course | 17:22 |
| srichter | it would be too much work to do | 17:22 |
| philiKON | btw, we need to review some of the changes | 17:23 |
| philiKON | e.g. the localService directive is a bit bogus | 17:23 |
| philiKON | i bet it doesn't exist anymore ;) | 17:23 |
| srichter | it might | 17:24 |
| srichter | I review the entries when I am preparing the release notes anyways | 17:24 |
| srichter | I always do that | 17:24 |
| srichter | also, there are entries that do not make it into X3.1, so they need to be moved to the future release section | 17:24 |
| philiKON | yup | 17:24 |
| srichter | I have that part under control :-) | 17:25 |
| philiKON | good | 17:25 |
| * philiKON kills the worry daemon | 17:25 | |
| srichter | as long as people add their changes to the CHANGES.txt file, I am perfectly happy | 17:25 |
| philiKON | here's one suggestion, though | 17:25 |
| philiKON | might make your life easier too | 17:25 |
| srichter | (searching for changes in the checkins is what kills you; I did that for X3.0 and it was painful) | 17:25 |
| *** bskahan has quit IRC | 17:26 | |
| philiKON | for example, the svn project's changes.txt has after each change the revision number | 17:26 |
| *** gintas has quit IRC | 17:27 | |
| *** bska|mobile has joined #zope3-dev | 17:28 | |
| srichter | totally OT: I was able to nest edit forms for the new preference system; it works so well with minimal effort; I am very positively surprised how well it works | 17:29 |
| *** tvon has quit IRC | 17:31 | |
| srichter | nested edit forms are much better than the object field and widget, imo | 17:31 |
| *** BjornT has joined #zope3-dev | 17:32 | |
| philiKON | srichter, so, how do you nest edit forms? | 17:32 |
| philiKON | (never tried the object field/widget either) | 17:32 |
| srichter | you have to write a custom constructor for the edit form class, so you do not get name clashes | 17:33 |
| srichter | then you simply need to tell your rendering template which fields should be treated in sub-editforms | 17:33 |
| srichter | I will checkin the code later today | 17:34 |
| philiKON | uh huh | 17:34 |
| philiKON | sounds ocmplicated | 17:34 |
| projekt01 | I like to see that ;-) | 17:34 |
| srichter | it is only 11 lines of Python and two templates + registration, one for the full edit form and one for the subforms | 17:35 |
| srichter | this is very little if you see that it can handle any level of nesting | 17:36 |
| AJC | philiKON, hmmm, just a quick question, is the file you mentioned actually named wcsite.page? if so, it's not in the archive... | 17:36 |
| philiKON | i meant it in package python notation | 17:37 |
| philiKON | so, wcsite/page/ is the directory you'll find the simple page implementation in | 17:37 |
| philiKON | wcsite/page/interfaces.py contains the IPage schema, wcsite/page/browser.py contains the browser view that does the rendering using zope.app.renderer | 17:38 |
| AJC | heh, that directory is missing then. | 17:38 |
| philiKON | the implementation of hte IPage schema in wcsite/page/page.py is very very trivial | 17:38 |
| philiKON | oh? | 17:38 |
| AJC | from wcsite-1.0.tgz, downloaded a few hours ago | 17:38 |
| philiKON | i might have restructured since then...? | 17:38 |
| *** tvon|desk has quit IRC | 17:39 | |
| philiKON | dang, you're right | 17:39 |
| AJC | hmm, i was starting to feel rather stupid :-) | 17:39 |
| philiKON | sorry about that | 17:40 |
| philiKON | you got an email, i'll send you a newer version | 17:40 |
| AJC | heh, don't worry... you're doing me/everyone a favour | 17:40 |
| *** palmTree has quit IRC | 17:42 | |
| *** bradb has joined #zope3-dev | 17:43 | |
| *** viyyer has quit IRC | 17:45 | |
| philiKON | AJC, http://worldcookery.com/files/wcsite-1.1.tgz | 17:46 |
| srichter | does anyone know how I can reference objects defined in a functional text file? | 17:46 |
| AJC | philiKON, you're a star, thanks. | 17:47 |
| mgedmin | srichter, could you be more specific? | 17:47 |
| srichter | mgedmin: I have defined an interface in my test file README.txt | 17:47 |
| srichter | mgedmin: I want to test my ZCML directives and I want to refer to this interface in ZCML | 17:48 |
| srichter | basically, I am testing my ZCML directives in the README.txt file | 17:48 |
| srichter | I know this used to work, but maybe it does not anymore | 17:48 |
| srichter | I thought it was __builtin__, but this does not work | 17:49 |
| philiKON | srichter, no, it's a bit trickier | 17:51 |
| philiKON | srichter, look at zope.app.publisher.xmlrpc.README.txt | 17:51 |
| philiKON | and the corresponding test harnace | 17:52 |
| philiKON | you basically need to publish the doctest module (Readme.txt) as a sys.modules | 17:52 |
| philiKON | then you can access it within your code as, say, zope.app.publisher.xmlrpc.README.SomeFooComponent | 17:52 |
| srichter | cool | 17:52 |
| philiKON | (i wish this would be possible out of the box, actually) | 17:52 |
| srichter | that's all I need | 17:52 |
| srichter | yep, me too | 17:53 |
| srichter | ick, this is complicated | 17:53 |
| srichter | maybe I should add this to zope.app.testing.setup | 17:54 |
| philiKON | that would be just great | 17:54 |
| srichter | yeah, then I just do that | 17:54 |
| srichter | maybe better in ztapi, actually | 17:55 |
| srichter | wow, this will even allow pickling | 17:56 |
| philiKON | srichter, quick question... where exactly does the TAL machinery invoke the translation machinery from zope.i18n...? do you happen to know? | 17:56 |
| srichter | in the engine | 17:56 |
| srichter | there is a translate method | 17:57 |
| philiKON | where's the engine? in .tal or in .pagetemplate? | 17:57 |
| srichter | see zope.tal.dummyengine line 197 | 17:57 |
| philiKON | but that's just dummy | 17:58 |
| srichter | the Zope 3 version is in zope.app.pagetemplate.engine line 113 | 17:58 |
| philiKON | aaaah | 17:58 |
| philiKON | perfect. thanks | 17:58 |
| srichter | np | 17:58 |
| philiKON | strange | 17:59 |
| philiKON | it's actually not the engine that has the translate() method, but the ZopeContextBase | 17:59 |
| *** Aiste has quit IRC | 17:59 | |
| srichter | which I think is effectively the engine | 18:00 |
| srichter | its all a bit strange, engine and context are really the same thing (I always forget the exact symmantics) | 18:00 |
| *** J1m has joined #zope3-dev | 18:06 | |
| AJC | hey, amazon.co.uk has 30% off your book philiKON, but amazon.de is full price :-) | 18:06 |
| d2m | springer.com is selling without VAT (just EUR 49,95 at the online store) | 18:07 |
| d2m | http://www.springeronline.com/sgw/cda/frontpage/0,11855,5-102-22-35029949-0,00.html to be correct | 18:10 |
| *** palmTree has joined #zope3-dev | 18:14 | |
| *** th1a has joined #zope3-dev | 18:16 | |
| srichter | philiKON: ok, got it working | 18:16 |
| srichter | its easy as it can be now | 18:17 |
| *** mgedmin has quit IRC | 18:21 | |
| *** Theuni has quit IRC | 18:24 | |
| *** alga has quit IRC | 18:33 | |
| *** palmTree has quit IRC | 18:41 | |
| AJC | srichter, you mentioned ZODB could easily handle all my needs from a database point of view, but is it sensible to have a large number of objects in a "folder"? (say 10k-100k) | 18:41 |
| srichter | yes | 18:41 |
| srichter | in zope 3 folders are always btrees | 18:41 |
| AJC | ok, cool. i guess the hard part is coming up with names for the objects :-) | 18:42 |
| srichter | you might want to write different views though, since a simple listing of all objects is not sensible anymore | 18:42 |
| philiKON | heh | 18:42 |
| AJC | srichter, good point... | 18:42 |
| srichter | AJC: when in doubt, let Zope 3 choose names :-) | 18:42 |
| srichter | AJC: we have the concept of a namechooser in Zope 3 | 18:43 |
| srichter | you could write your own implementation that constructs the name from the title, for example | 18:43 |
| AJC | well, if I chose good names they may come in handy later when i'm doing custom traversal (say to provide a /archive/<date>/<article> url) | 18:43 |
| AJC | oh, cool. i see | 18:43 |
| *** SteveA has quit IRC | 18:44 | |
| philiKON | actually, in my book i have the example of a namechooser choosing the name from the object's title | 18:44 |
| philiKON | :) | 18:44 |
| *** SteveA has joined #zope3-dev | 18:45 | |
| *** vlado_ has quit IRC | 18:48 | |
| *** zagy has quit IRC | 18:50 | |
| srichter | wow, the KDE project chose BitKeeper over Subversion due to conversion problems | 18:53 |
| philiKON | isn't bitkeeper commercial? | 18:55 |
| srichter | oh, never mind | 18:55 |
| srichter | its 4/1 | 18:55 |
| srichter | the last lines of the release were too odd | 18:56 |
| srichter | darn, I hate when that happens to me ;-) | 18:56 |
| srichter | I hate when one cannot believe the news they are reading on 4/1 | 18:57 |
| philiKON | :) | 18:57 |
| srichter | now it will be so difficult to filter /. news; better not read it today at all | 18:58 |
| * philiKON wishes some of the new laws that are taking effect today were just april fool's jokes | 19:00 | |
| srichter | which laws? the patent stuff? | 19:01 |
| philiKON | no, bank secret stuff | 19:05 |
| philiKON | government can now look into our bank accounts | 19:05 |
| philiKON | to determine whether you've declared all your taxes correctly | 19:06 |
| philiKON | i feel like 1984 | 19:06 |
| srichter | really? In Germany? | 19:06 |
| AJC | bah | 19:06 |
| * AJC stores money under the carpet | 19:07 | |
| srichter | thank god I just moved unregistered in Germany and I am now a US tax citizen only | 19:07 |
| philiKON | well, patriot act isn't better | 19:10 |
| philiKON | in some ways i think it's even worse | 19:10 |
| philiKON | but that doesn't change the fact that nobody really seems to care about all this | 19:10 |
| philiKON | haven't people learned since 1989?!? | 19:11 |
| *** bska|mobile has quit IRC | 19:12 | |
| *** bskahan has joined #zope3-dev | 19:16 | |
| *** lunatik has left #zope3-dev | 19:22 | |
| AJC | i'm off, have a great weekend! | 19:23 |
| *** AJC has quit IRC | 19:23 | |
| srichter | philiKON: obviously not | 19:28 |
| srichter | philiKON: the patriot act is bad in itself, but people start to challenge it in court now | 19:28 |
| srichter | (at least) | 19:28 |
| srichter | philiKON: by the way, I checked in the preference code, so you can look at the browser stuff and see the nested edit forms setup | 19:32 |
| philiKON | thanks | 19:32 |
| philiKON | srichter, for the doctest module thing, i thought you were gonna convert zope.app.publisher.xmlrpc.readme test to that too | 19:35 |
| srichter | yeah, I have not done that yet | 19:35 |
| srichter | I forgot | 19:35 |
| srichter | philiKON: done | 19:38 |
| philiKON | you're fast :) | 19:39 |
| srichter | it was just deleting a couple lines and running the tests :-) | 19:39 |
| *** SteveA has quit IRC | 19:39 | |
| *** mgedmin has joined #zope3-dev | 19:47 | |
| *** alga has joined #zope3-dev | 19:49 | |
| *** SteveA has joined #zope3-dev | 19:59 | |
| *** deo has joined #zope3-dev | 20:00 | |
| *** [apoirier] has quit IRC | 20:02 | |
| *** hazmat has quit IRC | 20:08 | |
| *** anguenot has quit IRC | 20:14 | |
| bradb | I'm writing an event handler in which I need to get the absolute URL of an object. Do I: 1. add the abs url as an attrib of the event or 2. include the request as a third object to adapt for the event handler or 3. use some global API to access the "current request"? (not sure if there is such a thing.) or 4. something else? :) | 20:19 |
| J1m | You should probably have the request be an attr of the event | 20:20 |
| bradb | doesn't that make my event handler code depend more on Z3 APIs than I want it to? | 20:21 |
| mgedmin | (it is possible to extract the "current request" from the current interaction, if you iterate through participations and find one that provides IBrowserRequest, btw) | 20:21 |
| mgedmin | (that doesn't mean it is a good idea to do that) | 20:21 |
| J1m | It is a bad idea | 20:21 |
| bradb | mgedmin: sounds extremely unmaintainable :) | 20:21 |
| * bradb wonders if the stock events should have the request as part of their API | 20:22 | |
| bradb | e.g. IObjectCreatedEvent et al. | 20:22 |
| J1m | No, absolutely not | 20:22 |
| bradb | ah, ok, i see | 20:23 |
| J1m | I don't know anything about your app, so it's rather hard to advise | 20:23 |
| bradb | because these events are specific to things created through a browser | 20:23 |
| bradb | er, *aren't* i meant | 20:23 |
| J1m | right | 20:23 |
| bradb | fair enough. I'll go with your suggestion to make my own request-aware events. thanks J1m. | 20:24 |
| tarek_ | hi all, there's this cool QueueProcessorThread in zope.email for async mail delivery. | 20:28 |
| tarek_ | i need to have a similar functionality for soemthing else, and i was wondering if it exists already : | 20:28 |
| tarek_ | i need to make async processes, on queue per session id | 20:29 |
| tarek_ | use case : | 20:29 |
| tarek_ | a view is calculated for the user, it ahs to make a call to another server. this call won't change the view but the call has to be done | 20:30 |
| tarek_ | so the view can be shown and the call send to a threaded queue | 20:30 |
| tarek_ | and this calls needs to be serialized per user | 20:31 |
| *** hazmat has joined #zope3-dev | 20:32 | |
| bradb | J1m: It's worth noting though that the current AddView would probably be much more useful to publish an event that does include the request as an attribute of the event, no? Same with EditView. They are, afterall, both BrowserViews. | 20:32 |
| *** alga_ has joined #zope3-dev | 20:33 | |
| *** d2m has quit IRC | 20:38 | |
| *** Arnia has joined #zope3-dev | 20:46 | |
| srichter | tarek_: no, there is no such functionality generally yet | 21:00 |
| srichter | but please feel free to factor out the queue code and make it a separate pacakge | 21:00 |
| tarek_ | srichter: ok i'll do that | 21:02 |
| * tarek_ needs to study first how session are dealt in Z3 | 21:04 | |
| *** bskahan has quit IRC | 21:07 | |
| *** tvon has joined #zope3-dev | 21:08 | |
| *** FarcePest has joined #zope3-dev | 21:10 | |
| *** alga_ has quit IRC | 21:20 | |
| *** efge has left #zope3-dev | 21:29 | |
| *** admp has quit IRC | 21:32 | |
| *** admp has joined #zope3-dev | 21:32 | |
| *** admp has quit IRC | 21:57 | |
| *** efge has joined #zope3-dev | 22:00 | |
| *** mgedmin has quit IRC | 22:05 | |
| *** alga has quit IRC | 22:09 | |
| *** ignas has quit IRC | 22:15 | |
| *** garrett-smith has joined #zope3-dev | 22:47 | |
| *** RaFromBRC|out is now known as RaFromBRC | 22:53 | |
| garrett-smith | J1m: I forgot to include 'login' in the principal folder's principal info implementation | 23:03 |
| garrett-smith | my plan is to just add it as an attribute and not bother creating a new interface for that type of info | 23:04 |
| *** PalmTree_ has joined #zope3-dev | 23:10 | |
| srichter | projekt01: did you check out the preferences stuff? | 23:16 |
| srichter | philiKON: are you there? | 23:25 |
| *** tvon has quit IRC | 23:32 | |
| *** palmTree__ has joined #zope3-dev | 23:39 | |
| *** niemeyer has quit IRC | 23:45 | |
| *** palmTree__ has quit IRC | 23:50 | |
| *** PalmTree_ has quit IRC | 23:56 | |
| *** nathany has joined #zope3-dev | 23:58 | |
| *** efge has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!