IRC log of #zope3-dev for Saturday, 2005-09-17

srichterwell, caching is not working for you then00:06
srichterit's always the same00:06
srichterI am not surprised anymore00:06
srichteror Tim forgot to publsih something00:07
srichternope, he sis specify an effective date00:07
srichterso it's the caching again...00:08
srichterd2m: can you have a look?00:08
srichterbtw, I get to it just fine00:08
d2msrichter: seems, that while you are uploading a release file a temporary object is created in 'private' state which blocks access to the release folder00:32
srichteryep, but when Jim wrote this message Tim and I were done for a long time00:33
d2msrichter: 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 too00:34
d2mthe 2.4 version was published at 2005-09-16 14:38:5800:35
d2mmust really be a caching issue then00:35
srichterI think so00:36
srichterespecially since often a trailing slash can make the difference00:36
d2mbut 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 published00:37
d2madding /folder_contents almost always works for anonymous00:37
srichteractually, I also think that the software is badly written00:38
srichtera new unpublished file should not be able to jam the entire folder00:38
d2mwell, with some 50 - 100 edits a day the whole workflow is a bit of a joke00:38
d2msomeone proposed to do the edits on an extra instance and make available for anonymous access00:40
srichtermmh, interesting idea00:41
d2mthere is not very much value added when you are logged in00:41
d2msrichter, with manager rights you can see all modifications of yesterday at (its almost the same on any other day)00:43
d2mit is mostly creating new memberfolders and default documents00:43
srichterI am not a manager throughout00:44
srichteronly under Products/Zope300:44
d2mi'll make you one there00:45
srichterok, thanks00:45
*** FarcePest has quit IRC00:47
J1msrichter, ayt?00:59
srichterJ1m: yes00:59
*** GaryPoster has quit IRC01:00
J1mDo you know that Tim would like you to let hin know when you are going to make a z3 release?01:02
*** d2m has quit IRC01:31
*** tanghus_ has joined #zope3-dev01:34
*** J1m has quit IRC01:38
*** tanghus has quit IRC01:49
yotasorry for another stupid question but what is pagelet ? I don't remember any items on zope3 books on this01:49
benji_yorkyota, 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 refactoring01:57
yotaok, a portlet like02:00
benji_yorkyota, not quite, but I've got to go02:09
*** benji_york has left #zope3-dev02:09
yotasrichter: demo pagelet chooser is still in zope3.1 ?02:16
*** MJ has quit IRC02:24
projekt01benji_york, I like the idea about rendering file based resources described in the Library proposal mail.02:31
*** ignas has joined #zope3-dev02:54
projekt01srichter, ayt?02:55
projekt01srichter, we have to discuss the macrochooser again02:59
projekt01The macrochooser was the part in the pagelet concept where is in reallity responsible for return pagelets03:01
projekt01I agree that this at the first time seems to be obsolate03:01
projekt01But since the adapter registry is responsible for return the pagelets we can't integrate some logic where is responsible for return pagelets03:02
projekt01This is straight forward but kills many use cases for pagelets.03:02
projekt01Do you have any idea how we can integrate logic now?03:03
projekt01Think 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-dev03:08
projekt01I 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
projekt01will be served/will be served or not03:11
*** drMental has joined #Zope3-dev03:14
*** bskahan has quit IRC03:50
*** vlado has joined #zope3-dev04:24
*** yota has quit IRC04:30
*** drMental has quit IRC04:37
projekt01srichter, now I understand what you did in the pagelet-rework branch05:02
projekt01that's a big difference to the pagelet implementation before.05:02
projekt01and I see also what you mean I mixed macros and pagelets which you think is too much.05:03
projekt01Pagelets are macros05:03
projekt01the reason why, we process them as macro code in the tales engine05:04
projekt01and have access to other variables in the page template from the pagelet macro code05:05
projekt01the simplification lost all this part because the pagelets are now only view classes where return rendered output05:06
projekt01and this output (normaly html) get rendered with the tal:replace="structure output" method05:07
projekt01and 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
projekt01I really think we should go back and use macro code and not a real view class for pagelets.05:10
projekt01Ok, I will write a mail tomorrow to you, I have to think about some parts.05:12
projekt01The most important decision I think is, should pagelets be macros or python classes?05:13
projekt01right now we have pagelets which are macros and the new implementation I would call viewlets05:17
projekt01perhaps we should add both of them and explain what they are.05:17
projekt01this would make it possible to use it without to break anything05:19
*** vlado has quit IRC05:19
*** oday has joined #zope3-dev05:49
*** projekt01 has quit IRC06:02
*** bradb has left #zope3-dev06:15
*** oday has quit IRC07:05
*** clueck has joined #zope3-dev07:55
*** BjornT has joined #zope3-dev08:21
*** clueck has quit IRC08:25
*** philiKON has quit IRC10:06
*** mexiKON has joined #zope3-dev10:09
*** d2m has joined #zope3-dev10:48
*** BjornT has quit IRC10:51
*** SureshZ has left #zope3-dev10:56
*** MJ has joined #zope3-dev11:15
*** BjornT has joined #zope3-dev11:34
*** ignas has quit IRC12:44
*** projekt01 has joined #zope3-dev12:46
*** mumak has joined #zope3-dev13:12
*** ignas has joined #zope3-dev13:13
srichterprojekt01: are you there?13:21
mumaksrichter: hi13:21
projekt01srichter, yup13:22
projekt01Did you see my mail?13:22
srichterI am still reading it13:22
srichterbut my immediate response would be that the macrochooser logic can go into the pagelet class itself13:22
srichteri.e. you can control whether __call__ returns something or not13:23
mumaksrichter: 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.113:24
projekt01srichter, but then is it to late because you render this already in the ZPT13:24
srichterI 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 it13:24
srichtermumak: right, you can add it to the branch13:25
mumaksrichter: thanks13:25
srichterprojekt01: no, it's not too late13:25
srichter__call__ renders a pagelet for ZPT13:25
srichterif you return an empty string instead of the rendered template, the pagelet template gets never rendered13:26
srichterbtw, the assertion in your E-mail that only the adapter registry decides upon the validity of a pagelet is not right13:27
srichterThe TALES pagelets namespace also does some filtering by deciding whether a pagelet can be accessed and determines the order by weight13:28
srichterOne thing that we could do is to implement a PageletFilter13:28
projekt01not true if you use <tal:block repeat="pag pagelets:iface"><div tal:content="pag">content</div><tal:block>13:28
projekt01you will get a empty div tag in the ZPT13:29
srichterok, you are right13:29
projekt01I 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
srichterthe PageletFilter would get a list of pagelets and it allows then the pagelets to be filtered13:30
*** vlado has joined #zope3-dev13:30
srichterIMacroCollector was very hard to understand13:30
projekt01The implementation yes, the function no. But you are right there was no documentation.13:31
srichterI see your point and you are right; what do you think about this:13:31
srichter1) Get pagelets from adapter registry13:31
srichter2) Sort out non-accessible pagelets13:31
srichter3) Lookup PageletFilter (registered for content, request, view, slot)13:32
srichter   a) if it does not find one skip filtering13:32
srichter   b) if it does find one filter the pagelets further with the filter13:32
srichter4) Sort pagelets by weight13:33
srichter5) Return the pagelets13:33
projekt011) this is done in your refactoring where I really think is very good.13:33
srichterbasically I added (3)13:34
projekt012 is done in the MacroCollector, dou you think we can simplyfie this part and call it filter13:34
srichterbut now I wonder whether the PageletFilter should also do (2) and (4)13:34
*** xenru has joined #zope3-dev13:34
projekt01Yes, of corse13:35
srichterthen it is more a PageletManager13:35
projekt01I'm sure now if you understand what the IMocroCollector does it's very simply to understand the code13:35
projekt01Yes, PageletManager will be OK for the naming13:36
srichterdarn, I see the use cases now13:36
projekt01It's just a hook for custom integration where we can use later.13:36
srichterespecially, if you think about the fact that you can have local versions of those13:37
srichterthen you could also implement manual ordering and so on13:37
projekt01For simply use case there is no need for a MacroCollector13:37
srichterok, I'll implement this13:37
projekt01Or store just pagelet names where the macro chooser knows how to handle in the annotation of a object13:37
projekt01the MacroChooser can be useful for aquise pagelet names for a context/view/slot13:39
projekt01The changes not this bad, we only have to integrate the IMacroCHooser adapter call and can use the old implementation.13:40
projekt01What dou you think? I guess a new Filter will end in the same implementation.13:40
srichterpretty much yes, but I am going to write it from scratch, since I want to document and motivate it correctly13:41
mexiKONsrichter, mumak, ok, i'll merge it to the branch13:41
srichteractually during my nature break I noticed that steps 1-5 should all be in the PageletMAnager13:41
mumakcool :)13:41
projekt01srichter, perhaps this is a good idea.13:42
projekt01btw, what do you think about pagelets are views now and in the old implementation macros?13:42
srichtermexiKON: 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 evolve13:42
srichterprojekt01: this was the best accomplishment of it all :-)13:42
srichterit is soo much easier now13:43
projekt01but 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
projekt01the first time I didn't recognize this. But now if I think about it I think they really should be macros13:45
projekt01The 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 pagelet13:46
projekt01In tiks we use this shared global variable for set a flag in the header where another pagelet reads and use it.13:47
srichterwell, we need to find a different solution13:48
projekt01There is now way for use to live without shared global TALES variables set in pagelets.13:48
srichterthe macro concept is too heavy and hard13:48
srichterand now that I think about it, pagelets should never depend on global vars in TAL13:48
srichterthat breaks their concept13:48
srichterthey are individual, independent viewlets13:49
srichterif you used globals it showed a flaw in your design13:49
srichterif you used globals it shows a flaw in your UI design13:49
srichteryou have access to the original view from a pagelet and thus you can get all the info you need from there13:50
mexiKONsrichter, ah, ok!13:51
srichtermexiKON: this just occured to me the other day too ;-)13:51
srichtermmh, I wonder whether the slot should determine which vars get passed to the call13:51
projekt01No, before a pagelet was responsible to set a flag for Javascript support like canDragAndDrop and another pagelet could support the right code.13:52
srichterthis way you could say: if you are filling this slot you can expect arguments x, y, z13:52
projekt01The view didn't know about that at all.13:52
srichteryeah, but I think this is flawed by design13:53
srichterbecause you destroy what you just created; independence of pagelets from another13:54
projekt01It's nothing more then a pendent to the javascipt variables. Some kind of ZPT variables where are global.13:54
srichterright, global vars anything are bad and should never be a column of software design13:55
projekt01If 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
srichterthey are just sometimes a necessary evil13:55
projekt01No, there are base concept in the ZPT level, of corse not anybody uses it.13:56
srichterbut read carefully what you just wrote13:56
srichteryou basically are saying that pagelets have an implicit dependence on the surroundings of the view13:56
srichterthis dependence is nowhere formalized13:56
srichterso we should find a way of formalizing it; I was suggesting to do this via slots13:57
projekt01Yes, this we can solve with your idea of slot variables, perhaps this is a really good idea.13:57
projekt01Then it would be perfect for me, slots can define or restrict the ZPT variable namesapce. And we have a macro collector (manager) for custom implementation13:59
srichter(no more macros ;-)13:59
projekt01And pagelets are macross like before, which is much powerfull is the scope of a ZPT13:59
srichterpagelet manager :-)13:59
projekt01A sorry, of corse14:00
srichterno, we do not make them macros again; I just find a way of getting to the ZPT variables14:00
projekt01Ok part is done by the slots now. Are you sure we have access to the variables at this time we process them?14:01
srichtermacros are (a) very hard to comprehend, (b) require a lot of boilerplate and (c) might go away at some point14:01
srichterI dunno, but I can do it hard-core using sys._getframe if necessary14:02
srichter(I hope I find a better way though)14:02
projekt01I'm fine if we have access to the tempalte variables in slots. (I hope I can do all usecases)14:02
projekt01Note 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
projekt01but we don't have access to global variables where defined below of the pagelet: TALES expression. (no way)14:05
projekt01Global ZPT variables are only global form the place they get set in the template till the end of a template.14:06
projekt01... that's a different where pipelines can solve sometimes.14:07
projekt01... in some way...14:07
srichteroh, that's right, the TALES namespace can get us the info14:07
projekt01Yes, see the old implementation, it's done already.14:08
*** xenru has quit IRC14:10
projekt01Sorry, I'm wrong it's implicit done because pagelet where macros before.14:11
srichterbut I am positive we can get to it from TALES14:11
projekt01But there you can access them: view = econtext.vars['view']14:12
srichterbecause TALES must be able to access environment variables14:12
projekt01I guess14:12
projekt01My last usecase, How can we support well-formed XHTML ZPT code?14:12
srichterok, so now we just need to agree upon a good way of specifying, which variables the pagelet should expect14:12
srichterhow is it possible to not support well-formed XHTML now?14:13
projekt01Hm, 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
projekt01Or not?14:15
srichteryeah, then don't do this :-)14:15
projekt01Then we have to write pagelets like <div>content</div>14:15
srichteryou have the same problem with regular macros too14:16
projekt01That are not well-formed XHMTL page anymore14:16
srichterwe do this sort of thing all the time14:16
projekt01Macros have the area above and below define macro14:16
srichterwhich make it much harder to read14:16
srichterI never used this feature in macros14:16
srichterit is very, very confusing14:17
projekt01Perhas 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
srichterI 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 way14:18
projekt01I think this is not a killer factor but remember there is no posibility to validate your HTML templates anymore14:19
srichterprojekt01: but it is still no good, because the code might look very different in the real pagelet14:19
srichterwell, I bet you could write a little script that simply puts the html and body tag around the code quickly and then validates14:20
projekt01But you can render them in firefox without a running zope. And not every developer can run a zope version for write pagelets !14:20
srichterminor annoyance if you consider the benefit14:21
projekt01What 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
projekt01or something like that14:22
srichterthe above is much more simple :-)14:22
projekt01I completly agree the we have to kill the macro and all this define use and fill concept of Macros14:22
srichterMETAL is already complicated enough; we should not make it more complicated14:23
mexiKON<div>content</div> is well-formed xml14:23
mexiKONit's not valid xhtml14:23
projekt01Ok, we have to find a way to strip at least the html and body area if defined in a ZPT file14:23
mexiKONmetal has this: define the macro only on the div14:24
d2msorry 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
projekt01mexiKON, but not well-formed XHTML and no way to validate and render it in firefox14:24
mexiKONd2m, uh, i hope macros aren't going away :)14:24
mexiKONprojekt01, dude, there's a difference between well-formed and valid14:24
mexiKONwell-formed xml means it can be parsed14:25
projekt01mexiKON, we will get rid of the complex metal concept14:25
projekt01mexiKON, ok you are right. I mean valid14:25
mexiKONvalid xhtml means the well-formed xml complies with a DTD14:25
srichterI think Jim wants to suggest alternative rendering mechanisms, such as pipelinging14:25
projekt01d2m, see the pagelet-rework implementation branch14:26
d2mthanks, will look there14:26
mexiKONprojekt01, what you want is to get rid of the static-ish macro system for skins14:26
mexiKONi hope you're not going to get rid of the zpt metal feature itself14:26
projekt01d2m, the big different is that pagelets return processed output from view classes, all the macro intageration is gone14:27
mexiKONi think metal is still a valid feature; just its use should be different (dynamic pagelets instead of static skin macros)14:27
mexiKONprojekt01, so, pagelets can be anything? not only metal?14:27
mexiKONprojekt01, so, pagelets can be anything? not only metal macros?14:27
projekt01I'm only happy with this if we can use the TALES namespace in slots, which is a better idea from srichter.14:27
srichterlook, we are talking here about METAL (support) in
srichterpagelets are views that are also qualified by the view and slot they are displayed in; nothing more14:28
srichter(well, a tiny little bit more is to it, but not conceptually)14:28
projekt01and before pagelets where macros where could interact in the TALES namespace with the template itself14:29
projekt01srichter, why do we not use bith concept and call the new one viewlets?14:30
srichterwe could14:30
projekt01pagelet will return macros and viewlets will return the view (__call__)14:30
projekt01Newbies can use viewlets for to get into this as a easy part and professional can use pagelets where understand what's happen.14:31
projekt01Newbies can use viewlets for to get into this as a easy part and professional can use pagelets where understand what's happen.14:31
mexiKONprojekt01, i like that idea14:32
mexiKONprojekt01, IViewlet and IPagelet would tell the difference between them14:32
srichterI really do not see the benefits of having macros around for pagelets14:32
mexiKONi had suggested anyway that pagelets become views providing IPagelet14:32
mexiKONsrichter, that pagelets can be valid xhtml documents14:33
srichterthat's how the new implementation does it14:33
mexiKONsrichter, ah, great14:33
mexiKONsrichter, so no stub object around just for adaption, eh?14:33
srichteryes, there is no way to avoid the stub slot obejct14:33
mexiKONyes, there is14:33
mexiKONmake slots decendants of IPagelet14:33
srichternot, if youwant o utilize the adapter registry14:34
srichterI thought of that14:34
mexiKONyou look up views providing ICSSRegion14:34
srichterbut it would break the contract14: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 snse14:34
mexiKONi dont' think it would necessarily break the contract14:35
mexiKONyou register the pagelet for a certain region14:35
srichterI think it will14:35
projekt01srichter, 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 MacroCollector14:35
srichterthe slot will define the input and output arguments/parameters14:35
mexiKONsrichter, 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 already14:35
mexiKONor maybe i don't fully understand where we would break the contract14:36
srichterno, 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
srichterplease let's not switch terminology14:36
projekt01mexiKOn, 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
mexiKONprojekt01, i don't think so14:37
* mexiKON switches back to slot terminology14:37
mexiKONlet's say i have a page composed of slot14:37
mexiKONlet's say i have a page composed of slots14:37
mexiKONe.g. ICSSSlot14:38
mexiKONfor ICSSSlot i expect a pagelet (or several ones) to fill it14:38
srichterprojekt01: but the point now is that if the slot describes the input variables, it makes really sense that the slot is the output interface14:38
mexiKONso, ICSSSlot extends IPagelet14:38
mexiKONi get in return a pagelet object14:38
mexiKONprovidng ICSSSlot14:38
mexiKONbecause that pagelet object was already registered for ICSSSlot14:38
mexiKONand since ICSSSlot objects are pagelets, the pagelet very well confirms the contract of being an IPagelet14:39
projekt01So this way the API of each pagelet must provide the same interface?14:39
projekt01No way14:39
projekt01How can I use pagelets from tiks and zope?14:39
mexiKONwell, pagelets must at least provide a minimum interface, IPagelet14:40
mexiKONwhatever IPagelet does14:40
mexiKONi guess it has a __call__14:40
projekt01doesn't provide the slot and won't get returned14:40
srichteractually IPagelet extends IBrowserView14:40
mexiKONsrichter, yeah, cool14:41
mexiKONprojekt01, you define slots like this: class CSSSlot(IPagelet): pass14:41
projekt01Remember a slot is used in a template as a key and I have to register for this slot and implement them.14:41
mexiKONand register your pagelet like  <view .... provides="...CSSSlot" />14:41
mexiKONprojekt01, yep, i am remembering that14:41
mexiKONi see no problem with this14:41
projekt01otheriwse I cant download pagelets form other packages where don't include his interface14:41
mexiKONhow would that be different now?14:42
srichterright, the slot determines how the pagelet interacts with the surroundings14:42
srichterprojekt01: yes, it can14:42
srichterit just needs to fulfill at least the same specs as the original slot interface14:43
projekt01hm, are you not saying that the Pagelet has to implement the slot interface?14:43
mexiKONprojekt01, exactly, i am saying that14:43
srichterprojekt01: the actual interface will be tagged to the class during pagelet registration time14:43
mexiKONprojekt01, what srichter says :)14:43
mexiKONyour code will probably always say:14:43
mexiKONclass MySuperCoolPagelet(object):14:43
mexiKON    implements(IPagelet)14:43
mexiKON     ....14:44
srichterbtw, do you guys have an idea on how we can specify the input arguments that a slot requires?14:44
mexiKONwhen you register it, however, you register it for ICSSSlot or whatever14:44
srichterdo we want to define them as fields ont eh slot interface?14:44
mexiKONsrichter, sounds good to me14:44
mexiKONvery clean way14:44
projekt01See wfmc formal paramters, I think the TALES expression can do this with kws14:44
mexiKONand they get settattr'd on the pagelet object14:44
srichterprojekt01: but I want to be a little more lightweight than wfmc14:45
projekt01really, support fields and widgets?14:45
srichtermexiKON: yeah, that sounds good to me too14:45
projekt01srichter, ;-)14:45
srichterwho said widgets? :-)14:45
mexiKONsrichter, that settattr-parameters convention is also done with widgets...14:46
projekt01Uhh, a pagelet before was only responsible for return macros and now it is a additional API14:46
srichterprojekt01: right, which is very good14:47
srichterprojekt01: because before it was not clear what the pagelet expected at all14:47
srichterprojekt01: you had all those implicit expectations; now the framework will force you to specify it14:47
mexiKONattributes are better than method parameters in this case IMO. unless we're talking about **kwargs parameters14:47
srichterthink of automatic documentation! :-)14:47
projekt01Of corse I will use widgets if this is possible, I think rendering additional widgets with pagelets will be really possible14:47
projekt01srichter, I agree it's better now!14:48
srichtermexiKON: I agree14:48
projekt01Ok, I think using fields is a good idea, so we can easy extract the values from the TALES namspace14:49
srichterI think once I implement the discussed changed, portlets might become very feasible14:49
srichterprojekt01: yep14:49
srichterand validate their value during testing14:49
srichter(to do it always would be too slow)14:49
projekt01srichter, 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
projekt01And viewlets are not a bad name for what the new concept represents.14:50
srichterif 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
projekt01I have fear about more poeple then I guess are suing pagelets14:51
srichtermmh, I am not too happy with viewlets14:51
srichterbut I am okay with it14:51
srichterprojekt01: I did not understand your last remark...14:52
projekt01If too many people use pagelets already we have a problem and will get a lot of comments14:53
srichterI am 95% sure that noone else is using it14:53
srichtermexiKON: have you used it already before?14:54
mexiKONsrichter, used what before?14:54
srichterI think noone understood the implementation before ;-)14:54
mexiKONsorry, was afk14:54
srichtermexiKON: pagelets14:54
projekt01I'm not sure since I know Daryl Cousins uses it in the e-commerce product and Da silva did also some changes on it14:54
mexiKONi looked at the impl14:54
mexiKONliked mostly what i saw14:54
mexiKONbut that stub object was always a big stain in my eye :)14:54
projekt01our project amadeus uses it and tiks at all uses it too14:54
mexiKONprojekt01, are you using the zope 3 catalog?14:55
srichterprojekt01: I said, someone other than th einventor :-)14:55
srichterprojekt01: but if it is too big of a burden for you to fix it to the new way, I am willing to rename it14:55
mexiKON*if* that happens, i'm rather +1 on viewlets and -1 on portlets14:56
srichteryeah, definitely!14:57
projekt01I think it will be a lot of work for me. And I have this time not now ;-(14:57
srichteralso, I think if we will implement local PageletManagers, we could easily implement JSR 160 style portlets based on what Jim explained to me14:57
srichterprojekt01: sure, I am sensitive to that14:58
srichterso I'll rename it to viewlet14:58
srichternow to the slot terminology14:58
projekt01I'm sure your changes and the useage of views instead of macros will open a wide door for future concepts14:58
srichteryay or nay for region?14:59
mexiKONslot is too much in people's minds for zpt metal macros14:59
srichterI like region better because slots are reserved for macro slots, which those never were and will be14:59
srichterI agree14:59
mexiKONif you want to introduce new concepts, you need new names... otherwise people will never evolve; that's my experience14:59
srichterprojekt01: thoughts, comments?14:59
projekt01I think view and region will fit better then pagelet and region15:00
srichterok, viewlet and region it will be then15:00
srichterI have to check in my first schooltool-based usage of pagelets and then I am working on the to do items15:01
srichterjust to summarize:15:01
projekt01take 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 them15:01
srichter(2) Make slots the output interface that extend IViewletl Slots also specify the available ZPT variables using fields15:02
srichter(3) Rename everything to viewlet and region15:02
srichteranything else?15:03
mexiKONi presume we will be able to read this again in prosa form in a proposal?15:03
mexiKONactually, doesn't have to be much more prosa than this above15:03
projekt01I'm really happy with this15:03
mexiKONyes, i'm also happy15:03
projekt01important will be a documentation where we can write at the sprint15:04
*** roym has joined #zope3-dev15:04
mexiKONexactly, a proposal which will later server as a good viewlet doc15:04
*** tanghus_ has quit IRC15:05
roymA question on the use of resourceDirectory:15:05
srichterthe README.txt file will have supurb docs :-)15:05
roymIn my application A, I have a subdirectory B and a resources subdir15:05
roymcalled R, such that I have a file A/B/R/custom.css; I have a15:05
roym<resourceDirectory declaration in my ZCML like:15:05
roym  <resourceDirectory15:05
roym    name="myR"15:05
roym    directory="R" />15:05
roymWhat *relative* path syntax can I use to access this file.  I find15:05
roymthat the following fails:15:05
roym  tal:attributes="href context/@@/myR/custom.css"15:05
projekt01srichter, 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
srichterprojekt01: ok, cool15:06
mexiKONprojekt01, +115:06
projekt01srichter, I'm away for 2 hours now, what can I do later?15:06
mexiKONroym, your conifugration file is in A/B/configure.zcml?15:06
roymmexiKON: yes15:07
mexiKONroym, also, context/@@/myR/custom.css isn't the right syntax15:07
roymdoes that work for "resourceDirectory" as well?15:07
srichterprojekt01: really only fix skintools and boston15:07
mexiKONroym, i think so15:07
srichterit will take me at least till Wednesday to finish the implementation; remember we have guests and they are about to get up15:08
*** yota has joined #zope3-dev15:08
projekt01srichter, if we only deprecate pagelets there is no need for this now.15:08
projekt01perhaps we have to add the deprecation message at the Boston skin15:08
projekt01refactoring at the neckar sprint15:09
roymmexiKON: it did - thanks a lot!!15:09
mexiKONroym, np... RTFM next time :)15:09
projekt01srichter, I guess there is no task for me now till the viewlets are implemented15:10
srichterok, got to do the morning bootup sequence; see ya later15:10
srichterprojekt01: right15:10
projekt01Ok, then I can work on my project subversion checkout tool ;-)15:11
projekt01srichter, philiKON, thanks a lot. I'm sure this refactoring will hive pagelets to the next state where is needed for acceptance.15:12
projekt01and give us a good base for additional concepts15:13
projekt01see you later...15:13
*** BjornT_ has joined #zope3-dev15: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 IRC15:17
*** BjornT has quit IRC15:19
*** mexiKON is now known as philiKON15:24
*** BjornT_ has quit IRC15:31
*** Aiste has joined #zope3-dev15:33
*** mumak has quit IRC16:49
*** faassen has joined #zope3-dev17:00
*** projekt01 has joined #zope3-dev17:29
*** loreto has joined #zope3-dev17:31
*** tvon has quit IRC17:37
*** loreto has quit IRC17:44
*** loreto has joined #zope3-dev17:59
*** tvon has joined #zope3-dev18:09
*** roym has quit IRC18:13
*** loreto has quit IRC18:22
*** loreto has joined #zope3-dev18:30
*** BjornT has joined #zope3-dev18:31
*** projekt01 has quit IRC18:43
*** loreto has quit IRC18:50
*** loreto has joined #zope3-dev18:53
*** Aiste has quit IRC19:13
*** loreto_ has joined #zope3-dev19:16
*** loreto has quit IRC19:16
*** loreto__ has joined #zope3-dev19:38
*** loreto_ has quit IRC19:38
*** loreto_ has joined #zope3-dev20:01
*** ksmith has joined #zope3-dev20:02
*** loreto__ has quit IRC20:03
*** drMental has joined #Zope3-dev20:21
*** loreto_ has quit IRC20:22
*** loreto_ has joined #zope3-dev20:27
*** hazmat has joined #zope3-dev20:43
*** ChanServ sets mode: +o hazmat20:43
*** loreto__ has joined #zope3-dev20:50
*** loreto_ has quit IRC20:50
*** loreto_ has joined #zope3-dev21:11
*** SureshZ has joined #zope3-dev21:12
*** loreto__ has quit IRC21:14
*** hazmat has quit IRC21:30
*** loreto__ has joined #zope3-dev21:34
*** loreto_ has quit IRC21:34
*** loreto__ has quit IRC21:43
*** loreto__ has joined #zope3-dev21:58
*** loreto__ has quit IRC22:17
*** loreto__ has joined #zope3-dev22:26
*** loreto__ has quit IRC22:32
*** loreto has joined #zope3-dev22:55
*** faassen has quit IRC22:57
*** loreto has quit IRC23:01
*** newpers has joined #zope3-dev23:08
newpershow does zope3 compare to a solution that uses mysql?23:09
bob2how are those things seperate?23:17
*** loreto has joined #zope3-dev23:20
*** drMental has quit IRC23:21
newperszop3 uses zodb, doesn't it?23:23
newperszodb is a object database23:23
newpersmysql is a relational database23:23
bob2it can also use mysql if you prefer23:23
newpersdidn't know that23:24
bob2zope3 is an application server, it can use any db (or none) that you want23:24
newpersbob2:  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 modi23:25
bob2zope3 is quite a nice solution23:25
bob2you can almost certainly find a pre-made tool for that, tho23:26
newperslike what?23:26
newpersi am trying to make a business around that tool23:26
newpersthat tool = such a tool23:26
newpersi 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
bob2is 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
bob2if the former, I'd use drupal23:27
newpersthe latter23:27
bob2good luck then23:28
newpersactually, in between23:28
*** SureshZ has quit IRC23:32
*** Aiste has joined #zope3-dev23:32
*** clueck has joined #zope3-dev23:37
clueckHey, bob223:40
*** loreto_ has joined #zope3-dev23:40
clueckYou had a problem concerning formlib some days ago23:40
clueckis there any progress?23:40
*** loreto_ has quit IRC23:47
*** Aiste has quit IRC23:49
*** Aiste has joined #zope3-dev23:49
newpersso, 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 IRC23:51

Generated by 2.15.1 by Marius Gedminas - find it at!