| srichter | well, caching is not working for you then | 00:06 |
|---|---|---|
| srichter | it's always the same | 00:06 |
| srichter | I am not surprised anymore | 00:06 |
| srichter | or Tim forgot to publsih something | 00:07 |
| srichter | nope, he sis specify an effective date | 00:07 |
| srichter | so it's the caching again... | 00:08 |
| srichter | d2m: can you have a look? | 00:08 |
| srichter | btw, I get to it just fine | 00:08 |
| d2m | srichter: seems, that while you are uploading a release file a temporary object is created in 'private' state which blocks access to the release folder | 00:32 |
| srichter | yep, but when Jim wrote this message Tim and I were done for a long time | 00:33 |
| d2m | srichter: when the upload is completed the file is renamed to the final id and the object is published, a bit later the portal_catalog is updated with the review_state too | 00:34 |
| d2m | the 2.4 version was published at 2005-09-16 14:38:58 | 00:35 |
| d2m | must really be a caching issue then | 00:35 |
| srichter | I think so | 00:36 |
| srichter | especially since often a trailing slash can make the difference | 00:36 |
| d2m | but the queued portal_catalog is a problem sometimes - when the review states are not updated in time access to folders can be denied, although the objects are already published | 00:37 |
| d2m | adding /folder_contents almost always works for anonymous | 00:37 |
| srichter | actually, I also think that the software is badly written | 00:38 |
| srichter | a new unpublished file should not be able to jam the entire folder | 00:38 |
| d2m | well, with some 50 - 100 edits a day the whole workflow is a bit of a joke | 00:38 |
| d2m | someone proposed to do the edits on an extra instance and make zope.org available for anonymous access | 00:40 |
| srichter | mmh, interesting idea | 00:41 |
| d2m | there is not very much value added when you are logged in | 00:41 |
| d2m | srichter, with manager rights you can see all modifications of yesterday at http://www.zope.org/Members/d2m/day2day/2005-09/2005-09-15_all (its almost the same on any other day) | 00:43 |
| d2m | it is mostly creating new memberfolders and default documents | 00:43 |
| srichter | I am not a manager throughout | 00:44 |
| srichter | only under Products/Zope3 | 00:44 |
| d2m | i'll make you one there | 00:45 |
| srichter | ok, thanks | 00:45 |
| *** FarcePest has quit IRC | 00:47 | |
| J1m | srichter, ayt? | 00:59 |
| srichter | J1m: yes | 00:59 |
| *** GaryPoster has quit IRC | 01:00 | |
| J1m | Do you know that Tim would like you to let hin know when you are going to make a z3 release? | 01:02 |
| srichter | yes | 01:05 |
| J1m | k | 01:11 |
| *** d2m has quit IRC | 01:31 | |
| *** tanghus_ has joined #zope3-dev | 01:34 | |
| *** J1m has quit IRC | 01:38 | |
| *** tanghus has quit IRC | 01:49 | |
| yota | sorry for another stupid question but what is pagelet ? I don't remember any items on zope3 books on this | 01:49 |
| benji_york | yota, I don't know much about pageletes, but the basic idea is that they're a page composition system, IOW you define pieces of content and places they will go. You might want to check out srichter's branch for more info on his refactoring | 01:57 |
| yota | ok, a portlet like | 02:00 |
| benji_york | yota, not quite, but I've got to go | 02:09 |
| *** benji_york has left #zope3-dev | 02:09 | |
| yota | srichter: demo pagelet chooser is still in zope3.1 ? | 02:16 |
| *** MJ has quit IRC | 02:24 | |
| projekt01 | benji_york, I like the idea about rendering file based resources described in the Library proposal mail. | 02:31 |
| *** ignas has joined #zope3-dev | 02:54 | |
| projekt01 | srichter, ayt? | 02:55 |
| projekt01 | srichter, we have to discuss the macrochooser again | 02:59 |
| projekt01 | The macrochooser was the part in the pagelet concept where is in reallity responsible for return pagelets | 03:01 |
| projekt01 | I agree that this at the first time seems to be obsolate | 03:01 |
| projekt01 | But since the adapter registry is responsible for return the pagelets we can't integrate some logic where is responsible for return pagelets | 03:02 |
| projekt01 | This is straight forward but kills many use cases for pagelets. | 03:02 |
| projekt01 | Do you have any idea how we can integrate logic now? | 03:03 |
| projekt01 | Think about the i18n use case. In the annotation of a object is defined which named pagelet should be used and the macrochooser will return this pagelet. | 03:05 |
| *** bskahan has joined #zope3-dev | 03:08 | |
| projekt01 | I don't think integrating the logic in the slot class can't handle the use case if a pagelet will be served. Then at this time it is to late because we call the pagelet itself already. | 03:11 |
| projekt01 | will be served/will be served or not | 03:11 |
| *** drMental has joined #Zope3-dev | 03:14 | |
| *** bskahan has quit IRC | 03:50 | |
| *** vlado has joined #zope3-dev | 04:24 | |
| *** yota has quit IRC | 04:30 | |
| *** drMental has quit IRC | 04:37 | |
| projekt01 | srichter, now I understand what you did in the pagelet-rework branch | 05:02 |
| projekt01 | that's a big difference to the pagelet implementation before. | 05:02 |
| projekt01 | and I see also what you mean I mixed macros and pagelets which you think is too much. | 05:03 |
| projekt01 | Pagelets are macros | 05:03 |
| projekt01 | the reason why, we process them as macro code in the tales engine | 05:04 |
| projekt01 | and have access to other variables in the page template from the pagelet macro code | 05:05 |
| projekt01 | the simplification lost all this part because the pagelets are now only view classes where return rendered output | 05:06 |
| projekt01 | and this output (normaly html) get rendered with the tal:replace="structure output" method | 05:07 |
| projekt01 | and pagelets can now return all what you need. Even other objects or utilities etc. It's a door we never like to open with pagelets. | 05:09 |
| projekt01 | I really think we should go back and use macro code and not a real view class for pagelets. | 05:10 |
| projekt01 | Ok, I will write a mail tomorrow to you, I have to think about some parts. | 05:12 |
| projekt01 | The most important decision I think is, should pagelets be macros or python classes? | 05:13 |
| projekt01 | right now we have pagelets which are macros and the new implementation I would call viewlets | 05:17 |
| projekt01 | perhaps we should add both of them and explain what they are. | 05:17 |
| projekt01 | this would make it possible to use it without to break anything | 05:19 |
| *** vlado has quit IRC | 05:19 | |
| *** oday has joined #zope3-dev | 05:49 | |
| *** projekt01 has quit IRC | 06:02 | |
| *** bradb has left #zope3-dev | 06:15 | |
| *** oday has quit IRC | 07:05 | |
| *** clueck has joined #zope3-dev | 07:55 | |
| *** BjornT has joined #zope3-dev | 08:21 | |
| *** clueck has quit IRC | 08:25 | |
| *** philiKON has quit IRC | 10:06 | |
| *** mexiKON has joined #zope3-dev | 10:09 | |
| *** d2m has joined #zope3-dev | 10:48 | |
| *** BjornT has quit IRC | 10:51 | |
| *** SureshZ has left #zope3-dev | 10:56 | |
| *** MJ has joined #zope3-dev | 11:15 | |
| *** BjornT has joined #zope3-dev | 11:34 | |
| *** ignas has quit IRC | 12:44 | |
| *** projekt01 has joined #zope3-dev | 12:46 | |
| *** mumak has joined #zope3-dev | 13:12 | |
| *** ignas has joined #zope3-dev | 13:13 | |
| srichter | projekt01: are you there? | 13:21 |
| mumak | srichter: hi | 13:21 |
| srichter | hi | 13:22 |
| projekt01 | srichter, yup | 13:22 |
| projekt01 | Did you see my mail? | 13:22 |
| srichter | I am still reading it | 13:22 |
| srichter | but my immediate response would be that the macrochooser logic can go into the pagelet class itself | 13:22 |
| srichter | i.e. you can control whether __call__ returns something or not | 13:23 |
| mumak | srichter: mexiKON just checked in a change to the implementedBy docstring. he said I should talk to you if I wanted the change to go into 3.1 | 13:24 |
| projekt01 | srichter, but then is it to late because you render this already in the ZPT | 13:24 |
| srichter | I would be open to have a mandatory "isAvailable()" (or similarly named) method on the pagelet view class that, if it returns False makes the pagelets TALES namespace not return it | 13:24 |
| srichter | mumak: right, you can add it to the branch | 13:25 |
| mumak | srichter: thanks | 13:25 |
| srichter | projekt01: no, it's not too late | 13:25 |
| srichter | __call__ renders a pagelet for ZPT | 13:25 |
| srichter | if you return an empty string instead of the rendered template, the pagelet template gets never rendered | 13:26 |
| srichter | btw, the assertion in your E-mail that only the adapter registry decides upon the validity of a pagelet is not right | 13:27 |
| srichter | The TALES pagelets namespace also does some filtering by deciding whether a pagelet can be accessed and determines the order by weight | 13:28 |
| srichter | One thing that we could do is to implement a PageletFilter | 13:28 |
| projekt01 | not true if you use <tal:block repeat="pag pagelets:iface"><div tal:content="pag">content</div><tal:block> | 13:28 |
| projekt01 | you will get a empty div tag in the ZPT | 13:29 |
| srichter | ok, you are right | 13:29 |
| projekt01 | I like to have a clear API for this like the IMacrooCollector is. That's a custom integration part. Why you don't like that? | 13:29 |
| srichter | the PageletFilter would get a list of pagelets and it allows then the pagelets to be filtered | 13:30 |
| *** vlado has joined #zope3-dev | 13:30 | |
| srichter | IMacroCollector was very hard to understand | 13:30 |
| projekt01 | The implementation yes, the function no. But you are right there was no documentation. | 13:31 |
| srichter | I see your point and you are right; what do you think about this: | 13:31 |
| srichter | 1) Get pagelets from adapter registry | 13:31 |
| srichter | 2) Sort out non-accessible pagelets | 13:31 |
| srichter | 3) Lookup PageletFilter (registered for content, request, view, slot) | 13:32 |
| srichter | a) if it does not find one skip filtering | 13:32 |
| srichter | b) if it does find one filter the pagelets further with the filter | 13:32 |
| srichter | 4) Sort pagelets by weight | 13:33 |
| srichter | 5) Return the pagelets | 13:33 |
| projekt01 | 1) this is done in your refactoring where I really think is very good. | 13:33 |
| srichter | basically I added (3) | 13:34 |
| projekt01 | 2 is done in the MacroCollector, dou you think we can simplyfie this part and call it filter | 13:34 |
| srichter | but now I wonder whether the PageletFilter should also do (2) and (4) | 13:34 |
| *** xenru has joined #zope3-dev | 13:34 | |
| projekt01 | Yes, of corse | 13:35 |
| srichter | then it is more a PageletManager | 13:35 |
| projekt01 | I'm sure now if you understand what the IMocroCollector does it's very simply to understand the code | 13:35 |
| projekt01 | Yes, PageletManager will be OK for the naming | 13:36 |
| srichter | darn, I see the use cases now | 13:36 |
| projekt01 | It's just a hook for custom integration where we can use later. | 13:36 |
| srichter | especially, if you think about the fact that you can have local versions of those | 13:37 |
| srichter | then you could also implement manual ordering and so on | 13:37 |
| projekt01 | For simply use case there is no need for a MacroCollector | 13:37 |
| projekt01 | Yes | 13:37 |
| srichter | ok, I'll implement this | 13:37 |
| projekt01 | Or store just pagelet names where the macro chooser knows how to handle in the annotation of a object | 13:37 |
| projekt01 | the MacroChooser can be useful for aquise pagelet names for a context/view/slot | 13:39 |
| projekt01 | The changes not this bad, we only have to integrate the IMacroCHooser adapter call and can use the old implementation. | 13:40 |
| projekt01 | What dou you think? I guess a new Filter will end in the same implementation. | 13:40 |
| srichter | pretty much yes, but I am going to write it from scratch, since I want to document and motivate it correctly | 13:41 |
| mexiKON | srichter, mumak, ok, i'll merge it to the branch | 13:41 |
| srichter | actually during my nature break I noticed that steps 1-5 should all be in the PageletMAnager | 13:41 |
| mumak | cool :) | 13:41 |
| projekt01 | srichter, perhaps this is a good idea. | 13:42 |
| projekt01 | btw, what do you think about pagelets are views now and in the old implementation macros? | 13:42 |
| srichter | mexiKON: the reason being, that if RC 3 becomes final, I will use the RC 3 tag to make the final tag, so the branch can evolve | 13:42 |
| srichter | projekt01: this was the best accomplishment of it all :-) | 13:42 |
| srichter | it is soo much easier now | 13:43 |
| projekt01 | but that is a huge conceptual changes. Now the pagelets are not well formed XHTML anymore and can be used as a additional API in general. | 13:45 |
| projekt01 | the first time I didn't recognize this. But now if I think about it I think they really should be macros | 13:45 |
| projekt01 | The processing in the TALES engine is now done for each pagelet, there is no shared namespace, this means you can't read a global ZPT variable in another pagelet | 13:46 |
| projekt01 | In tiks we use this shared global variable for set a flag in the header where another pagelet reads and use it. | 13:47 |
| srichter | well, we need to find a different solution | 13:48 |
| projekt01 | There is now way for use to live without shared global TALES variables set in pagelets. | 13:48 |
| srichter | the macro concept is too heavy and hard | 13:48 |
| srichter | and now that I think about it, pagelets should never depend on global vars in TAL | 13:48 |
| srichter | that breaks their concept | 13:48 |
| srichter | they are individual, independent viewlets | 13:49 |
| srichter | if you used globals it showed a flaw in your design | 13:49 |
| srichter | if you used globals it shows a flaw in your UI design | 13:49 |
| srichter | you have access to the original view from a pagelet and thus you can get all the info you need from there | 13:50 |
| mexiKON | srichter, ah, ok! | 13:51 |
| srichter | mexiKON: this just occured to me the other day too ;-) | 13:51 |
| srichter | mmh, I wonder whether the slot should determine which vars get passed to the call | 13:51 |
| projekt01 | No, before a pagelet was responsible to set a flag for Javascript support like canDragAndDrop and another pagelet could support the right code. | 13:52 |
| srichter | this way you could say: if you are filling this slot you can expect arguments x, y, z | 13:52 |
| projekt01 | The view didn't know about that at all. | 13:52 |
| srichter | yeah, but I think this is flawed by design | 13:53 |
| srichter | because you destroy what you just created; independence of pagelets from another | 13:54 |
| projekt01 | It's nothing more then a pendent to the javascipt variables. Some kind of ZPT variables where are global. | 13:54 |
| srichter | right, global vars anything are bad and should never be a column of software design | 13:55 |
| projekt01 | If a ZPT varaible is global then it has to accessible by a pagelets. Or if a ZPT varaible is local and the Pagelet is in this scope then this local variables have to be accessible. | 13:55 |
| srichter | they are just sometimes a necessary evil | 13:55 |
| projekt01 | No, there are base concept in the ZPT level, of corse not anybody uses it. | 13:56 |
| srichter | but read carefully what you just wrote | 13:56 |
| srichter | you basically are saying that pagelets have an implicit dependence on the surroundings of the view | 13:56 |
| srichter | this dependence is nowhere formalized | 13:56 |
| srichter | so we should find a way of formalizing it; I was suggesting to do this via slots | 13:57 |
| projekt01 | Yes, this we can solve with your idea of slot variables, perhaps this is a really good idea. | 13:57 |
| projekt01 | Then it would be perfect for me, slots can define or restrict the ZPT variable namesapce. And we have a macro collector (manager) for custom implementation | 13:59 |
| srichter | (no more macros ;-) | 13:59 |
| projekt01 | And pagelets are macross like before, which is much powerfull is the scope of a ZPT | 13:59 |
| projekt01 | ;-) | 13:59 |
| srichter | pagelet manager :-) | 13:59 |
| projekt01 | A sorry, of corse | 14:00 |
| srichter | no, we do not make them macros again; I just find a way of getting to the ZPT variables | 14:00 |
| projekt01 | Ok part is done by the slots now. Are you sure we have access to the variables at this time we process them? | 14:01 |
| srichter | macros are (a) very hard to comprehend, (b) require a lot of boilerplate and (c) might go away at some point | 14:01 |
| srichter | I dunno, but I can do it hard-core using sys._getframe if necessary | 14:02 |
| srichter | (I hope I find a better way though) | 14:02 |
| projekt01 | I'm fine if we have access to the tempalte variables in slots. (I hope I can do all usecases) | 14:02 |
| projekt01 | Note the engine processes the variable serial. Future variables are not set if we process the template. But I think we can access the scope where the pagelet belongs and that's enough. | 14:04 |
| projekt01 | but we don't have access to global variables where defined below of the pagelet: TALES expression. (no way) | 14:05 |
| projekt01 | Global ZPT variables are only global form the place they get set in the template till the end of a template. | 14:06 |
| srichter | right | 14:07 |
| projekt01 | ... that's a different where pipelines can solve sometimes. | 14:07 |
| projekt01 | ... in some way... | 14:07 |
| srichter | oh, that's right, the TALES namespace can get us the info | 14:07 |
| projekt01 | Yes, see the old implementation, it's done already. | 14:08 |
| srichter | where? | 14:08 |
| *** xenru has quit IRC | 14:10 | |
| projekt01 | Sorry, I'm wrong it's implicit done because pagelet where macros before. | 14:11 |
| srichter | right | 14:11 |
| srichter | but I am positive we can get to it from TALES | 14:11 |
| projekt01 | But there you can access them: view = econtext.vars['view'] | 14:12 |
| srichter | because TALES must be able to access environment variables | 14:12 |
| projekt01 | I guess | 14:12 |
| srichter | right | 14:12 |
| projekt01 | Yes | 14:12 |
| projekt01 | My last usecase, How can we support well-formed XHTML ZPT code? | 14:12 |
| srichter | ok, so now we just need to agree upon a good way of specifying, which variables the pagelet should expect | 14:12 |
| srichter | how is it possible to not support well-formed XHTML now? | 14:13 |
| projekt01 | Hm, perhaps I'm wrong but I f you use a page template for register a pagelet, and use <html>content</html> you get this as a return in the template if you call this pagelet. | 14:15 |
| projekt01 | Or not? | 14:15 |
| srichter | yeah, then don't do this :-) | 14:15 |
| projekt01 | Then we have to write pagelets like <div>content</div> | 14:15 |
| srichter | you have the same problem with regular macros too | 14:16 |
| srichter | yep | 14:16 |
| projekt01 | That are not well-formed XHMTL page anymore | 14:16 |
| projekt01 | No | 14:16 |
| srichter | we do this sort of thing all the time | 14:16 |
| projekt01 | Macros have the area above and below define macro | 14:16 |
| srichter | which make it much harder to read | 14:16 |
| srichter | I never used this feature in macros | 14:16 |
| srichter | it is very, very confusing | 14:17 |
| projekt01 | Perhas it's confusing for python developer, but it's one of the parts where HTML are very happy about, because the can validate the code with standard tools ;-) | 14:18 |
| srichter | I am very happy not to support this anymore; I can see the original use case for it, but it is more evil than good by a long way | 14:18 |
| projekt01 | I think this is not a killer factor but remember there is no posibility to validate your HTML templates anymore | 14:19 |
| srichter | projekt01: but it is still no good, because the code might look very different in the real pagelet | 14:19 |
| srichter | well, I bet you could write a little script that simply puts the html and body tag around the code quickly and then validates | 14:20 |
| projekt01 | But you can render them in firefox without a running zope. And not every developer can run a zope version for write pagelets ! | 14:20 |
| srichter | '<html><body>'+zpt_source+</body | 14:20 |
| srichter | validate('<html><body>'+zpt_source+</body></html>') | 14:20 |
| srichter | minor annoyance if you consider the benefit | 14:21 |
| projekt01 | What about to use and extract it generic, perhaps we need a additional function for this in metal. Like <html><metal:block insert="">pagelet code<metal:block></html> | 14:21 |
| projekt01 | or something like that | 14:22 |
| srichter | the above is much more simple :-) | 14:22 |
| projekt01 | I completly agree the we have to kill the macro and all this define use and fill concept of Macros | 14:22 |
| srichter | METAL is already complicated enough; we should not make it more complicated | 14:23 |
| mexiKON | <div>content</div> is well-formed xml | 14:23 |
| mexiKON | it's not valid xhtml | 14:23 |
| projekt01 | Ok, we have to find a way to strip at least the html and body area if defined in a ZPT file | 14:23 |
| mexiKON | metal has this: define the macro only on the div | 14:24 |
| d2m | sorry for talking in between; if macros (METAL) will go away, what will it be replaced with ? are ther any docs about that already ? | 14:24 |
| mexiKON | <html><body><div metal:define-macro="a-div">...</div></body></html> | 14:24 |
| projekt01 | mexiKON, but not well-formed XHTML and no way to validate and render it in firefox | 14:24 |
| mexiKON | d2m, uh, i hope macros aren't going away :) | 14:24 |
| mexiKON | projekt01, dude, there's a difference between well-formed and valid | 14:24 |
| mexiKON | well-formed xml means it can be parsed | 14:25 |
| projekt01 | mexiKON, we will get rid of the complex metal concept | 14:25 |
| projekt01 | mexiKON, ok you are right. I mean valid | 14:25 |
| mexiKON | valid xhtml means the well-formed xml complies with a DTD | 14:25 |
| srichter | I think Jim wants to suggest alternative rendering mechanisms, such as pipelinging | 14:25 |
| projekt01 | d2m, see the pagelet-rework implementation branch | 14:26 |
| d2m | thanks, will look there | 14:26 |
| mexiKON | projekt01, what you want is to get rid of the static-ish macro system for skins | 14:26 |
| mexiKON | i hope you're not going to get rid of the zpt metal feature itself | 14:26 |
| projekt01 | d2m, the big different is that pagelets return processed output from view classes, all the macro intageration is gone | 14:27 |
| mexiKON | i think metal is still a valid feature; just its use should be different (dynamic pagelets instead of static skin macros) | 14:27 |
| mexiKON | aha | 14:27 |
| mexiKON | projekt01, so, pagelets can be anything? not only metal? | 14:27 |
| mexiKON | projekt01, so, pagelets can be anything? not only metal macros? | 14:27 |
| projekt01 | I'm only happy with this if we can use the TALES namespace in slots, which is a better idea from srichter. | 14:27 |
| srichter | look, we are talking here about METAL (support) in zope.app.pagelets | 14:28 |
| srichter | pagelets are views that are also qualified by the view and slot they are displayed in; nothing more | 14:28 |
| srichter | (well, a tiny little bit more is to it, but not conceptually) | 14:28 |
| projekt01 | and before pagelets where macros where could interact in the TALES namespace with the template itself | 14:29 |
| projekt01 | srichter, why do we not use bith concept and call the new one viewlets? | 14:30 |
| projekt01 | bith/both | 14:30 |
| srichter | we could | 14:30 |
| projekt01 | pagelet will return macros and viewlets will return the view (__call__) | 14:30 |
| srichter | naeh | 14:30 |
| projekt01 | Newbies can use viewlets for to get into this as a easy part and professional can use pagelets where understand what's happen. | 14:31 |
| projekt01 | Newbies can use viewlets for to get into this as a easy part and professional can use pagelets where understand what's happen. | 14:31 |
| mexiKON | projekt01, i like that idea | 14:32 |
| mexiKON | projekt01, IViewlet and IPagelet would tell the difference between them | 14:32 |
| srichter | I really do not see the benefits of having macros around for pagelets | 14:32 |
| mexiKON | i had suggested anyway that pagelets become views providing IPagelet | 14:32 |
| mexiKON | srichter, that pagelets can be valid xhtml documents | 14:33 |
| srichter | that's how the new implementation does it | 14:33 |
| mexiKON | srichter, ah, great | 14:33 |
| mexiKON | srichter, so no stub object around just for adaption, eh? | 14:33 |
| srichter | yes, there is no way to avoid the stub slot obejct | 14:33 |
| mexiKON | yes, there is | 14:33 |
| mexiKON | make slots decendants of IPagelet | 14:33 |
| srichter | not, if youwant o utilize the adapter registry | 14:34 |
| srichter | I thought of that | 14:34 |
| mexiKON | you look up views providing ICSSRegion | 14:34 |
| srichter | but it would break the contract | 14:34 |
| mexiKON | (i prefer "region" instead of "slot") | 14:34 |
| srichter | *however*, in light of the new way we want to be able to pass in variables to a pagelet, this just might make snse | 14:34 |
| mexiKON | i dont' think it would necessarily break the contract | 14:35 |
| mexiKON | you register the pagelet for a certain region | 14:35 |
| srichter | I think it will | 14:35 |
| projekt01 | srichter, your refactoring can also go to the pagelet and viewlet as well. I think then we could also only use the MacroCollctor in pagelets as well and the viewlets don't use MacroCollector | 14:35 |
| srichter | the slot will define the input and output arguments/parameters | 14:35 |
| mexiKON | srichter, when your egister a pagelet for ICSSRegion or IBodyRegion, the pagelet will have to provide this. pagelets from ZPT files could automatically be marked with this interface already | 14:35 |
| mexiKON | or maybe i don't fully understand where we would break the contract | 14:36 |
| srichter | no, I decided that the PageletManager is a very good thing and should always be availabel :-) The pagelet selection does not belong logically int he TALES namespace implementation :-) | 14:36 |
| srichter | please let's not switch terminology | 14:36 |
| projekt01 | mexiKOn, if we get rid of the slot/region as a wrapper class, then we get a mess between the provided intreface of a pagelet and what we get as a return (pagelet) | 14:37 |
| mexiKON | projekt01, i don't think so | 14:37 |
| * mexiKON switches back to slot terminology | 14:37 | |
| mexiKON | let's say i have a page composed of slot | 14:37 |
| mexiKON | let's say i have a page composed of slots | 14:37 |
| mexiKON | e.g. ICSSSlot | 14:38 |
| mexiKON | for ICSSSlot i expect a pagelet (or several ones) to fill it | 14:38 |
| srichter | projekt01: but the point now is that if the slot describes the input variables, it makes really sense that the slot is the output interface | 14:38 |
| mexiKON | so, ICSSSlot extends IPagelet | 14:38 |
| srichter | yep | 14:38 |
| mexiKON | i get in return a pagelet object | 14:38 |
| mexiKON | providng ICSSSlot | 14:38 |
| mexiKON | because that pagelet object was already registered for ICSSSlot | 14:38 |
| mexiKON | and since ICSSSlot objects are pagelets, the pagelet very well confirms the contract of being an IPagelet | 14:39 |
| projekt01 | So this way the API of each pagelet must provide the same interface? | 14:39 |
| projekt01 | No way | 14:39 |
| projekt01 | How can I use pagelets from tiks and zope? | 14:39 |
| mexiKON | well, pagelets must at least provide a minimum interface, IPagelet | 14:40 |
| mexiKON | whatever IPagelet does | 14:40 |
| mexiKON | i guess it has a __call__ | 14:40 |
| srichter | yep | 14:40 |
| projekt01 | doesn't provide the slot and won't get returned | 14:40 |
| srichter | actually IPagelet extends IBrowserView | 14:40 |
| mexiKON | srichter, yeah, cool | 14:41 |
| mexiKON | projekt01, you define slots like this: class CSSSlot(IPagelet): pass | 14:41 |
| projekt01 | Remember a slot is used in a template as a key and I have to register for this slot and implement them. | 14:41 |
| mexiKON | and register your pagelet like <view .... provides="...CSSSlot" /> | 14:41 |
| mexiKON | projekt01, yep, i am remembering that | 14:41 |
| mexiKON | i see no problem with this | 14:41 |
| projekt01 | otheriwse I cant download pagelets form other packages where don't include his interface | 14:41 |
| mexiKON | wellll | 14:42 |
| mexiKON | how would that be different now? | 14:42 |
| srichter | right, the slot determines how the pagelet interacts with the surroundings | 14:42 |
| srichter | projekt01: yes, it can | 14:42 |
| srichter | it just needs to fulfill at least the same specs as the original slot interface | 14:43 |
| projekt01 | hm, are you not saying that the Pagelet has to implement the slot interface? | 14:43 |
| mexiKON | projekt01, exactly, i am saying that | 14:43 |
| srichter | projekt01: the actual interface will be tagged to the class during pagelet registration time | 14:43 |
| mexiKON | projekt01, what srichter says :) | 14:43 |
| mexiKON | your code will probably always say: | 14:43 |
| mexiKON | class MySuperCoolPagelet(object): | 14:43 |
| mexiKON | implements(IPagelet) | 14:43 |
| mexiKON | .... | 14:44 |
| srichter | btw, do you guys have an idea on how we can specify the input arguments that a slot requires? | 14:44 |
| mexiKON | when you register it, however, you register it for ICSSSlot or whatever | 14:44 |
| srichter | do we want to define them as fields ont eh slot interface? | 14:44 |
| mexiKON | srichter, sounds good to me | 14:44 |
| mexiKON | very clean way | 14:44 |
| projekt01 | See wfmc formal paramters, I think the TALES expression can do this with kws | 14:44 |
| mexiKON | and they get settattr'd on the pagelet object | 14:44 |
| srichter | ok | 14:45 |
| srichter | projekt01: but I want to be a little more lightweight than wfmc | 14:45 |
| projekt01 | really, support fields and widgets? | 14:45 |
| srichter | mexiKON: yeah, that sounds good to me too | 14:45 |
| projekt01 | srichter, ;-) | 14:45 |
| srichter | who said widgets? :-) | 14:45 |
| mexiKON | srichter, that settattr-parameters convention is also done with widgets... | 14:46 |
| projekt01 | Uhh, a pagelet before was only responsible for return macros and now it is a additional API | 14:46 |
| srichter | yep | 14:46 |
| srichter | projekt01: right, which is very good | 14:47 |
| srichter | projekt01: because before it was not clear what the pagelet expected at all | 14:47 |
| srichter | projekt01: you had all those implicit expectations; now the framework will force you to specify it | 14:47 |
| mexiKON | attributes are better than method parameters in this case IMO. unless we're talking about **kwargs parameters | 14:47 |
| srichter | think of automatic documentation! :-) | 14:47 |
| projekt01 | Of corse I will use widgets if this is possible, I think rendering additional widgets with pagelets will be really possible | 14:47 |
| projekt01 | srichter, I agree it's better now! | 14:48 |
| srichter | mexiKON: I agree | 14:48 |
| projekt01 | Ok, I think using fields is a good idea, so we can easy extract the values from the TALES namspace | 14:49 |
| srichter | I think once I implement the discussed changed, portlets might become very feasible | 14:49 |
| srichter | projekt01: yep | 14:49 |
| srichter | and validate their value during testing | 14:49 |
| srichter | (to do it always would be too slow) | 14:49 |
| projekt01 | srichter, I thin we should rename pagelets to viewlets, just for BBB and deprecate them, this will make it possible to switch without break anything. | 14:50 |
| projekt01 | And viewlets are not a bad name for what the new concept represents. | 14:50 |
| srichter | if I would be an ass, I would say now that I do not have to worry about BBB, since it has never been released :-) | 14:51 |
| projekt01 | I have fear about more poeple then I guess are suing pagelets | 14:51 |
| srichter | mmh, I am not too happy with viewlets | 14:51 |
| srichter | but I am okay with it | 14:51 |
| srichter | projekt01: I did not understand your last remark... | 14:52 |
| projekt01 | If too many people use pagelets already we have a problem and will get a lot of comments | 14:53 |
| srichter | I am 95% sure that noone else is using it | 14:53 |
| srichter | mexiKON: have you used it already before? | 14:54 |
| mexiKON | srichter, used what before? | 14:54 |
| srichter | I think noone understood the implementation before ;-) | 14:54 |
| mexiKON | sorry, was afk | 14:54 |
| srichter | mexiKON: pagelets | 14:54 |
| mexiKON | no | 14:54 |
| projekt01 | I'm not sure since I know Daryl Cousins uses it in the e-commerce product and Da silva did also some changes on it | 14:54 |
| mexiKON | i looked at the impl | 14:54 |
| mexiKON | liked mostly what i saw | 14:54 |
| mexiKON | but that stub object was always a big stain in my eye :) | 14:54 |
| projekt01 | our project amadeus uses it and tiks at all uses it too | 14:54 |
| mexiKON | projekt01, are you using the zope 3 catalog? | 14:55 |
| srichter | projekt01: I said, someone other than th einventor :-) | 14:55 |
| mexiKON | :) | 14:55 |
| projekt01 | ;-) | 14:55 |
| srichter | projekt01: but if it is too big of a burden for you to fix it to the new way, I am willing to rename it | 14:55 |
| mexiKON | *if* that happens, i'm rather +1 on viewlets and -1 on portlets | 14:56 |
| srichter | yeah, definitely! | 14:57 |
| projekt01 | I think it will be a lot of work for me. And I have this time not now ;-( | 14:57 |
| srichter | also, I think if we will implement local PageletManagers, we could easily implement JSR 160 style portlets based on what Jim explained to me | 14:57 |
| srichter | projekt01: sure, I am sensitive to that | 14:58 |
| srichter | so I'll rename it to viewlet | 14:58 |
| srichter | now to the slot terminology | 14:58 |
| projekt01 | I'm sure your changes and the useage of views instead of macros will open a wide door for future concepts | 14:58 |
| srichter | yay or nay for region? | 14:59 |
| mexiKON | yay | 14:59 |
| mexiKON | slot is too much in people's minds for zpt metal macros | 14:59 |
| srichter | I like region better because slots are reserved for macro slots, which those never were and will be | 14:59 |
| srichter | I agree | 14:59 |
| mexiKON | if you want to introduce new concepts, you need new names... otherwise people will never evolve; that's my experience | 14:59 |
| srichter | projekt01: thoughts, comments? | 14:59 |
| projekt01 | I think view and region will fit better then pagelet and region | 15:00 |
| srichter | ok, viewlet and region it will be then | 15:00 |
| srichter | I have to check in my first schooltool-based usage of pagelets and then I am working on the to do items | 15:01 |
| srichter | just to summarize: | 15:01 |
| projekt01 | take a view to this nice regions and see the trees at the top of the mountains make seens in natural laguages ;-) | 15:01 |
| srichter | (1) Implement a Viewlet Manager that is responsible for selecting the viewlets and sort them | 15:01 |
| srichter | (2) Make slots the output interface that extend IViewletl Slots also specify the available ZPT variables using fields | 15:02 |
| srichter | (3) Rename everything to viewlet and region | 15:02 |
| srichter | <over> | 15:02 |
| srichter | anything else? | 15:03 |
| mexiKON | i presume we will be able to read this again in prosa form in a proposal? | 15:03 |
| mexiKON | actually, doesn't have to be much more prosa than this above | 15:03 |
| projekt01 | I'm really happy with this | 15:03 |
| mexiKON | yes, i'm also happy | 15:03 |
| projekt01 | important will be a documentation where we can write at the sprint | 15:04 |
| *** roym has joined #zope3-dev | 15:04 | |
| mexiKON | exactly, a proposal which will later server as a good viewlet doc | 15:04 |
| *** tanghus_ has quit IRC | 15:05 | |
| roym | A question on the use of resourceDirectory: | 15:05 |
| srichter | the README.txt file will have supurb docs :-) | 15:05 |
| roym | In my application A, I have a subdirectory B and a resources subdir | 15:05 |
| roym | called R, such that I have a file A/B/R/custom.css; I have a | 15:05 |
| roym | <resourceDirectory declaration in my ZCML like: | 15:05 |
| roym | 15:05 | |
| roym | <resourceDirectory | 15:05 |
| roym | name="myR" | 15:05 |
| roym | directory="R" /> | 15:05 |
| roym | 15:05 | |
| roym | What *relative* path syntax can I use to access this file. I find | 15:05 |
| roym | that the following fails: | 15:05 |
| roym | tal:attributes="href context/@@/myR/custom.css" | 15:05 |
| projekt01 | srichter, philiKON, I think then I also know my Neckar sprint task. Implement viewlets in the Boston skin and make the nested menus working too. | 15:05 |
| srichter | projekt01: ok, cool | 15:06 |
| mexiKON | projekt01, +1 | 15:06 |
| projekt01 | srichter, I'm away for 2 hours now, what can I do later? | 15:06 |
| mexiKON | roym, your conifugration file is in A/B/configure.zcml? | 15:06 |
| roym | mexiKON: yes | 15:07 |
| mexiKON | roym, also, context/@@/myR/custom.css isn't the right syntax | 15:07 |
| mexiKON | context/++resource++myR/custom.css | 15:07 |
| roym | does that work for "resourceDirectory" as well? | 15:07 |
| srichter | projekt01: really only fix skintools and boston | 15:07 |
| mexiKON | roym, i think so | 15:07 |
| srichter | it will take me at least till Wednesday to finish the implementation; remember we have guests and they are about to get up | 15:08 |
| *** yota has joined #zope3-dev | 15:08 | |
| projekt01 | srichter, if we only deprecate pagelets there is no need for this now. | 15:08 |
| projekt01 | perhaps we have to add the deprecation message at the Boston skin | 15:08 |
| projekt01 | refactoring at the neckar sprint | 15:09 |
| roym | mexiKON: it did - thanks a lot!! | 15:09 |
| mexiKON | roym, np... RTFM next time :) | 15:09 |
| projekt01 | srichter, I guess there is no task for me now till the viewlets are implemented | 15:10 |
| srichter | ok, got to do the morning bootup sequence; see ya later | 15:10 |
| srichter | projekt01: right | 15:10 |
| projekt01 | Ok, then I can work on my project subversion checkout tool ;-) | 15:11 |
| projekt01 | srichter, philiKON, thanks a lot. I'm sure this refactoring will hive pagelets to the next state where is needed for acceptance. | 15:12 |
| projekt01 | and give us a good base for additional concepts | 15:13 |
| projekt01 | see you later... | 15:13 |
| *** BjornT_ has joined #zope3-dev | 15:15 | |
| projekt01 | ... btw, I'm looking forward to prototype some widget integration for pagelets since there will be a schema in the new concept ;-) | 15:15 |
| *** projekt01 has quit IRC | 15:17 | |
| *** BjornT has quit IRC | 15:19 | |
| *** mexiKON is now known as philiKON | 15:24 | |
| *** BjornT_ has quit IRC | 15:31 | |
| *** Aiste has joined #zope3-dev | 15:33 | |
| *** mumak has quit IRC | 16:49 | |
| *** faassen has joined #zope3-dev | 17:00 | |
| *** projekt01 has joined #zope3-dev | 17:29 | |
| *** loreto has joined #zope3-dev | 17:31 | |
| *** tvon has quit IRC | 17:37 | |
| *** loreto has quit IRC | 17:44 | |
| *** loreto has joined #zope3-dev | 17:59 | |
| *** tvon has joined #zope3-dev | 18:09 | |
| *** roym has quit IRC | 18:13 | |
| *** loreto has quit IRC | 18:22 | |
| *** loreto has joined #zope3-dev | 18:30 | |
| *** BjornT has joined #zope3-dev | 18:31 | |
| *** projekt01 has quit IRC | 18:43 | |
| *** loreto has quit IRC | 18:50 | |
| *** loreto has joined #zope3-dev | 18:53 | |
| *** Aiste has quit IRC | 19:13 | |
| *** loreto_ has joined #zope3-dev | 19:16 | |
| *** loreto has quit IRC | 19:16 | |
| *** loreto__ has joined #zope3-dev | 19:38 | |
| *** loreto_ has quit IRC | 19:38 | |
| *** loreto_ has joined #zope3-dev | 20:01 | |
| *** ksmith has joined #zope3-dev | 20:02 | |
| *** loreto__ has quit IRC | 20:03 | |
| *** drMental has joined #Zope3-dev | 20:21 | |
| *** loreto_ has quit IRC | 20:22 | |
| *** loreto_ has joined #zope3-dev | 20:27 | |
| *** hazmat has joined #zope3-dev | 20:43 | |
| *** ChanServ sets mode: +o hazmat | 20:43 | |
| *** loreto__ has joined #zope3-dev | 20:50 | |
| *** loreto_ has quit IRC | 20:50 | |
| *** loreto_ has joined #zope3-dev | 21:11 | |
| *** SureshZ has joined #zope3-dev | 21:12 | |
| *** loreto__ has quit IRC | 21:14 | |
| *** hazmat has quit IRC | 21:30 | |
| *** loreto__ has joined #zope3-dev | 21:34 | |
| *** loreto_ has quit IRC | 21:34 | |
| *** loreto__ has quit IRC | 21:43 | |
| *** loreto__ has joined #zope3-dev | 21:58 | |
| *** loreto__ has quit IRC | 22:17 | |
| *** loreto__ has joined #zope3-dev | 22:26 | |
| *** loreto__ has quit IRC | 22:32 | |
| *** loreto has joined #zope3-dev | 22:55 | |
| *** faassen has quit IRC | 22:57 | |
| *** loreto has quit IRC | 23:01 | |
| *** newpers has joined #zope3-dev | 23:08 | |
| newpers | how does zope3 compare to a solution that uses mysql? | 23:09 |
| bob2 | how are those things seperate? | 23:17 |
| *** loreto has joined #zope3-dev | 23:20 | |
| *** drMental has quit IRC | 23:21 | |
| newpers | zop3 uses zodb, doesn't it? | 23:23 |
| newpers | zodb is a object database | 23:23 |
| bob2 | indeed | 23:23 |
| newpers | mysql is a relational database | 23:23 |
| bob2 | it can also use mysql if you prefer | 23:23 |
| newpers | didn't know that | 23:24 |
| bob2 | zope3 is an application server, it can use any db (or none) that you want | 23:24 |
| newpers | thanks | 23:24 |
| newpers | bob2: maybe you can help me with something. i'm trying to create this cms system for 8 clients. they will all use the same system, but have different websites (urls). on their site they will have a blog, classifieds, and website with pictures and descriptions. in addition, each website will have multiple users with different permisisons that can change the content. is zope the ideal solution for this? or would using plone and modi | 23:25 |
| bob2 | zope3 is quite a nice solution | 23:25 |
| bob2 | you can almost certainly find a pre-made tool for that, tho | 23:26 |
| newpers | like what? | 23:26 |
| newpers | i am trying to make a business around that tool | 23:26 |
| newpers | that tool = such a tool | 23:26 |
| bob2 | okiedokie | 23:26 |
| newpers | i mentioned that, because i would like to know if it would still be best to find a pre-made tool that does this? | 23:27 |
| bob2 | is your goal to do it as quickly as possible for your customers, or to make a complex solution that will cost them lots? | 23:27 |
| bob2 | if the former, I'd use drupal | 23:27 |
| newpers | the latter | 23:27 |
| bob2 | good luck then | 23:28 |
| newpers | actually, in between | 23:28 |
| newpers | lol | 23:28 |
| *** SureshZ has quit IRC | 23:32 | |
| *** Aiste has joined #zope3-dev | 23:32 | |
| *** clueck has joined #zope3-dev | 23:37 | |
| clueck | Hey, bob2 | 23:40 |
| *** loreto_ has joined #zope3-dev | 23:40 | |
| clueck | You had a problem concerning formlib some days ago | 23:40 |
| clueck | is there any progress? | 23:40 |
| *** loreto_ has quit IRC | 23:47 | |
| *** Aiste has quit IRC | 23:49 | |
| *** Aiste has joined #zope3-dev | 23:49 | |
| newpers | so, is zope overkill for a site that needs content management for just a few blog type entries and tabulated data? | 23:49 |
| *** loreto has quit IRC | 23:51 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!