RE: [Zope3-dev] Zope 3.1
Hi Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Chris Withers > Sent: Monday, October 17, 2005 10:09 AM > To: [EMAIL PROTECTED] > Cc: zope3-dev@zope.org; 'Tim Peters' > Subject: Re: [Zope3-dev] Zope 3.1 > > Hi Roger, > > Roger Ineichen wrote: > > The main question is, what's the base "source" for build the Zope3 > > application server. I guess this will be generated by zpkgtools > > in some way. > > If I understand zpkgtools correct, we can use it for checkout the > > source. > > Right. > > > The step after the checkout isn't clear to me right now > > for windows. > > Tim posted a URL in another thread which I hope should clear > that up... > it may (and hopefully will!) mean more to you than it does for me... > > > We also have to define how Zope3 get installed on a windows > > machine. I don't like the normal installation where is > located in the > > python installation root right now. > > Is that where it ends up on Linux? If so, then we should > respect that... That's not a normal pattern for windows. But I agree it's the way how python application get installed. But that doesn't mean it's correct for every usecase. > > This means we whould offer a > > installation "by instance" where we don't share the zope/python > > libraries, located in the python installation root, and don't need > > to run "mkzopeinstance". > > I'm -1 on this... How whould you install two different version of z3 if you share the libraries? Ok, perhpas that's not a normal use case. But we have to support this with a installer. There are two concepts for install applications on windows. 1. Applications can be installed on time on a server if they use hard coded version seetings or they will override previouse installtion settings in the "Software Panel" 2. Application can be installed per instance. in this case the insteller has to use "instance" settings for store it's info n the "Software Panel". Otheriwse we will override the installation data and are not able to unsinstall more the one zope3 server. But this is only required if we don't install the source to the python installation root. For me it's a must to install zope3 as a running application rater then install the source to python on a windows system and use mkzopeinstance. I really think mkzopeinstance should be a part of the installation process. > > The best way to do all required steps would be a sprint. I guess > > if the right people are there, it's possible to improve all parts > > where we need in 3 or 4 days. > > I guess you're volunteering to organise one then? ;-) That's not a problem if somebody likes to come to switzerland. Tell me if you are interessted and I can organize a workshop. > > btw, > > A option for backup the Data.fs should also be integrated in the > > update (installation) process. > > Don't really follow that... Backup has nothing to do with > setup/install > for me... I don't understand that, everytime I run a update I backup the data before. I don't think that's bad idea. But I agree not every installer supports this. I normaly implement in each installer a backup option. You only have to use them if you like it. btw, why should we not offer a backup option for the Data.fs during backup? Regards Roger Ineichen > cheers, > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
Stephan Richter wrote: On Monday 17 October 2005 12:21, Gary Poster wrote: Similarly to your comments, I'm worried about viewlets getting in Zope 3.2 without addressing the update problem, myself. Maybe you can simply put an XXX or a warning and be happy with it: not my call. :-) No, I will not distribute it unless we are in agreement. I will probably merge the work into the trunk though, because I want SchoolTool to use it. ;-) Regards, Stephan Hi, I have just read the examples of Content provider and Viewlets and find them _really_ great, and even easier to understand than the present implementation of views with METAL macros, while providing unlimited possibilities. I have a two small questions however : * If I decide to create a brand new skin, based heavily on content provider and viewlets, which sounds easier to do than the present way to do it, how should I provide the "glue" between the components which are not "content provider-capable" yet ? * By creating the content provider, I could gather information from various kinds of object and provide a composite view of them. Is that right ? Thanks in advance, Stéphane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] how to create a "release tarball" from svn-checkout of Z3.1.0?
Thank you Fred. Read the Friendly Zope3 Site, ha! Your response does beg the question though - of the packages on the branch *not* included in the Z3.1.0 release, which are considered to be "optional-good" and "optional-not-ready-for-prime-time"? I have read that SchoolTool/Schoolbell needed zope.app.wfmc, and I thought there might be other current Z3 apps "useful for study", that might need optional packages... thank you, ---mark Fred Drake writes: > On 10/17/05, Mark R. Biggers <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I would like to create a "release tarball" for a Linux system, from a > > svn checkout of: > > Instructions on creating a source tarball can be found here: > > http://dev.zope.org/Zope3/MakingARelease > > > The 'zope.org' tarball (and the Ubunutu "breezy" package) for > > Zope-3.1.0 is missing the zope.app.wfmc package, and I don't know what > > else may be missing. > > These packages were either determined not to be ready or to be > optional features. Either of these reasons would keep the package > from being included in the tarball. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Monday 17 October 2005 12:21, Gary Poster wrote: > > I think this can only happen, if we can get Roger, Benji, you and > > me at the > > same location for a couple of days. Our ues cases are somewhat > > different, but > > all equally important, especially the "update bug" of yours. > > Sounds great to me in theory. ;-) Well, at least some of us have to meet. I could probably come to F12g for a couple of days. > Similarly to your comments, I'm worried about viewlets getting in > Zope 3.2 without addressing the update problem, myself. Maybe you > can simply put an XXX or a warning and be happy with it: not my > call. :-) No, I will not distribute it unless we are in agreement. I will probably merge the work into the trunk though, because I want SchoolTool to use it. ;-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 12:17 PM, Stephan Richter wrote: Thanks for your thoughts and review. ... I really want to talk to you over a higher-bandwidth medium about this. If we could agree on everything but the persistent bits for the 3.2 inclusion then I'd be thrilled. That will mean a number of things have to align though, including our perspectives. :-) I think this can only happen, if we can get Roger, Benji, you and me at the same location for a couple of days. Our ues cases are somewhat different, but all equally important, especially the "update bug" of yours. Sounds great to me in theory. ;-) Similarly to your comments, I'm worried about viewlets getting in Zope 3.2 without addressing the update problem, myself. Maybe you can simply put an XXX or a warning and be happy with it: not my call. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Monday 17 October 2005 12:07, Gary Poster wrote: > On Oct 17, 2005, at 12:02 PM, Stephan Richter wrote: > > Right, this is a serious problem. I would really like to see some more > > detailed documentation about this approach. But I am pretty sure > > this is a > > problem orthogonal to the content provider code and can be solved in a > > different package that then just has to work well with the others. > > I thought that was what I was proposing. Do I misunderstand your > point, then? Great! :-) Then we are on the same page. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 12:08 PM, Stephan Richter wrote: On Saturday 15 October 2005 15:48, Gary Poster wrote: I also really wish we could agree on a subview-addressing story (for AJAX) and a drag-and-drop story. We have experience with our drag and drop story, and are proposing a new AJAX story for subviews. The subview package only sets up some small foundations so that these can work. This is the reason we have not fully explored implementing portlets yet. I think those type of features are only interesting in very dynamic, CMS-like applications. For example, currently I do not need any of this for SchoolTool. Understood; as mentioned, the subview package offers an underlying agreement, which is important for interoperability. It shouldn't require SchoolTool to do much of anything except perhaps the subview container interface... I'll think about that some more. The persistence use cases are real and important, and I'd like to agree on them, but - we're still having internal discussions about the right way to do it, - it's intended to be an optional part of the subview capabilities, and - it doesn't appear to be pertinent to the viewlet or contentprovider approaches. I really think that sub-views need to be adapters and their state should be stored using a well-defined API. More than that I cannot say, because I have not thought about it. :-) Jim agrees with your assertion, to my knowledge. I am on the fence. Benji disgrees, last I checked. I have certain goals, which I hope to talk through with Jim and also offer up here on the list when I get to it. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Saturday 15 October 2005 15:48, Gary Poster wrote: > The rough README is here: http://svn.zope.org/Zope3/branches/ > f12gsprint-widget/src/zope/subview/README.txt?view=auto . The whole > package is rough; I had to put work on this aside, but it it is > currently slated to be my next project, since we need some of the > capabilities. Some random comments: - I am glad our URL-scheme for subviews/portlets is pretty much identical. However, this shows me again, that subview's purpose is far above that of content providers and viewlets. - You solve your render-bug problem using a container. If we could make this more of a conceptual container that simply collects all views to be used in a site, then I think this could work very well with content providers and viewlets. This is indeed a hard issue. Right now I see no way how you could flexibly provide additional subviews simply by registration, i.e. solve the viewlet/viewlet manager use case. I really want to talk to you over a higher-bandwidth medium about this. > If we could agree on everything but the persistent bits for the 3.2 > inclusion then I'd be thrilled. That will mean a number of things > have to align though, including our perspectives. :-) I think this can only happen, if we can get Roger, Benji, you and me at the same location for a couple of days. Our ues cases are somewhat different, but all equally important, especially the "update bug" of yours. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 11:59 AM, Stephan Richter wrote: On Saturday 15 October 2005 15:48, Gary Poster wrote: The most important part of my reply, though, is that I hope we can agree to share an even lower-level interface than contentproviders. If we do, it will address my remaining concerns (expressed below). I have been working on a subview package off in another branch. It addresses a class of bugs caused by subviews that affect non- contained subviews; sets the stage for AJAX components and for independently-configurable drag and drop between subviews; and wants to contemplate subview persistence as an optional addition. Note that I think that AJAX, drag-and-drop and all of this stuff is much, much higher level than even viewlets, let alone content providers. Both, content providers and viewlets, APIs have nothing to say about the interaction with the view or other content providers/viewlets. This type of contract was purposefully deferred to higher level APIs. For example, in SchoolTool we have no need for those type of things. Right, which is why the contract in subview is all about the parts of the decisions necessary for interoperability, rather than actual AJAX or drag and drop implementation. SchoolTool and other similar projects should have to do nothing or virtually nothing to "get along". The subview package includes no JS, for instance; some might live in zope.app.subview as an example of one way to use the agreements. You also include "all of this stuff": not sure what you are including there. If you mean prefixes and a two-stage update/render pattern, I flat out disagree with you. From another reply, I don't think you do. If you mean a persistence mechanism, then this is an opt-out part of the pattern that nonetheless is important to define at a low level: if a subview is not persistent or otherwise stateful then it dirties any containing subviews so that it is no longer persistent, even if the container thinks it is. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Saturday 15 October 2005 15:48, Gary Poster wrote: > I also really wish we could agree on a subview-addressing story (for > AJAX) and a drag-and-drop story. We have experience with our drag > and drop story, and are proposing a new AJAX story for subviews. The > subview package only sets up some small foundations so that these can > work. This is the reason we have not fully explored implementing portlets yet. I think those type of features are only interesting in very dynamic, CMS-like applications. For example, currently I do not need any of this for SchoolTool. > The persistence use cases are real and important, and I'd like to > agree on them, but > - we're still having internal discussions about the right way to do it, > - it's intended to be an optional part of the subview capabilities, and > - it doesn't appear to be pertinent to the viewlet or contentprovider > approaches. I really think that sub-views need to be adapters and their state should be stored using a well-defined API. More than that I cannot say, because I have not thought about it. :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 12:02 PM, Stephan Richter wrote: Right, this is a serious problem. I would really like to see some more detailed documentation about this approach. But I am pretty sure this is a problem orthogonal to the content provider code and can be solved in a different package that then just has to work well with the others. I thought that was what I was proposing. Do I misunderstand your point, then? Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Saturday 15 October 2005 15:48, Gary Poster wrote: > I have been working on a subview package off in another branch. It > addresses a class of bugs caused by subviews that affect non- > contained subviews; sets the stage for AJAX components and for > independently-configurable drag and drop between subviews; and wants > to contemplate subview persistence as an optional addition. > > Of these, my biggest concern is the first. When building our portlet > system, we discovered a class of rendering bugs that occur when a > change to a subview affects other subviews (usually non-nested): the > underlying data changes as expected but it is not drawn to screen > because the data change was out of order for the rendering. The two > stage approach, calculating all state and then rendering all, is the > solution we came up with for mitigating what we called 'update > bugs'. We have significant experience with the two stage approach, > and it is our best answer so far. You do not do this, or have > another solution I can see that addresses the same problems. We > would want this. Right, this is a serious problem. I would really like to see some more detailed documentation about this approach. But I am pretty sure this is a problem orthogonal to the content provider code and can be solved in a different package that then just has to work well with the others. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Saturday 15 October 2005 15:48, Gary Poster wrote: > The most important part of my reply, though, is that I hope we can > agree to share an even lower-level interface than contentproviders. > If we do, it will address my remaining concerns (expressed below). > > I have been working on a subview package off in another branch. It > addresses a class of bugs caused by subviews that affect non- > contained subviews; sets the stage for AJAX components and for > independently-configurable drag and drop between subviews; and wants > to contemplate subview persistence as an optional addition. Note that I think that AJAX, drag-and-drop and all of this stuff is much, much higher level than even viewlets, let alone content providers. Both, content providers and viewlets, APIs have nothing to say about the interaction with the view or other content providers/viewlets. This type of contract was purposefully deferred to higher level APIs. For example, in SchoolTool we have no need for those type of things. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Saturday 15 October 2005 15:48, Gary Poster wrote: > viewlets look like a clever pattern. I can see that they can be > applied to many use cases; I'll have to think about them to see how > much I like the application compared to others we have used, but I > have a generally favorable impression so far. > > contentproviders are a subset of the viewlet pattern, obviously. But > when do you think one might build contentproviders and not viewlets? > Do you have concrete use cases (or even current uses) for this division? While developing viewlets, we noticed that it was hard for us to keep the concerns apart. Content providers are a direct mapping to Java's content providers and provide a clean API to page templates, specifically. Viewlets are one way of using content providers to make the UI flexible. Viewlets fulfill a bunch of use cases Roger and I (as for SchoolTool) have. After a discussion with Benji this weekend, I am almost certain that viewlets will *not* be the base for the portlet code, since they make some assumptions about containment, which are very useful, but undesirable for portlets. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] how to create a "release tarball" from svn-checkout of Z3.1.0?
On 10/17/05, Mark R. Biggers <[EMAIL PROTECTED]> wrote: > Hello, > > I would like to create a "release tarball" for a Linux system, from a > svn checkout of: Instructions on creating a source tarball can be found here: http://dev.zope.org/Zope3/MakingARelease > The 'zope.org' tarball (and the Ubunutu "breezy" package) for > Zope-3.1.0 is missing the zope.app.wfmc package, and I don't know what > else may be missing. These packages were either determined not to be ready or to be optional features. Either of these reasons would keep the package from being included in the tarball. To include them in a distribution built according to the instructions, you'll need to name the additional packages you want in the releases/Zope/DEPENDENCIES.cfg file. -Fred -- Fred L. Drake, Jr. "Society attacks early, when the individual is helpless." --B.F. Skinner ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
On Oct 17, 2005, at 11:23 AM, Dominik Huber wrote: ... IMO it is very important to provide a standardized way to handle complex, formbased views properly (-> prefix like nested widgets) Agreed. FWIW, this is another part of the subview package. I tried to spell this out very explicitly. If contentproviders agreed on the subview interfaces, or something like them, then we would have a lower level agreement for all of the page component technologies out there. and to sketch the difference between widgets and viewlets out. The zope.widget package in the branch is currently in disrepair, but the intent is for widgets to be subviews. The subview package actually grew out of the widget work. This won't be ready for 3.2. I personally don't think that I want default widget look-up to require (context, request, view), as opposed to the current (context, request), so I'd be in favor of widget interfaces extending the subview interfaces, not the contentprovider interface. If for some reason someone wanted a widget system with lookups based on contentprovider then that could be an additional layer, still using all of the (context, request)-based code. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] how to create a "release tarball" from svn-checkout of Z3.1.0?
Hello, I would like to create a "release tarball" for a Linux system, from a svn checkout of: svn checkout svn://svn.zope.org/repos/main/Zope3/branches/Zope-3.1 [ I've googled about for this info...] The 'zope.org' tarball (and the Ubunutu "breezy" package) for Zope-3.1.0 is missing the zope.app.wfmc package, and I don't know what else may be missing. I've tried doing the SVN checkout as "Zope/" under the 3.1.0 tarball-unpack, running configure, ..., but that doesn't really work. Goal: to run './configure -blah blah; make; make test; make install", and have this put a complete Z3 install under a single dir-tree. That's one (of many) reasons why the tarball is convenient and useful... thank you, mark ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Content Providers and Viewlets
Hi Stephan, I just looked at the examples. I like the current implementation much more, because a viewlet is adapted to its original context (-> complex example) and content providers (or viewlet managers) can render itself. Those changes are providing a better encapsulation and a more ca-like comprehension. Cool - Thank you very much! IMO it is very important to provide a standardized way to handle complex, formbased views properly (-> prefix like nested widgets) and to sketch the difference between widgets and viewlets out. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.1
Hi Roger, Roger Ineichen wrote: The main question is, what's the base "source" for build the Zope3 application server. I guess this will be generated by zpkgtools in some way. If I understand zpkgtools correct, we can use it for checkout the source. Right. The step after the checkout isn't clear to me right now for windows. Tim posted a URL in another thread which I hope should clear that up... it may (and hopefully will!) mean more to you than it does for me... We also have to define how Zope3 get installed on a windows machine. I don't like the normal installation where is located in the python installation root right now. Is that where it ends up on Linux? If so, then we should respect that... This means we whould offer a installation "by instance" where we don't share the zope/python libraries, located in the python installation root, and don't need to run "mkzopeinstance". I'm -1 on this... The best way to do all required steps would be a sprint. I guess if the right people are there, it's possible to improve all parts where we need in 3 or 4 days. I guess you're volunteering to organise one then? ;-) btw, A option for backup the Data.fs should also be integrated in the update (installation) process. Don't really follow that... Backup has nothing to do with setup/install for me... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Changes to zope3 windows binary installer
Tim Peters wrote: The bad news is that Martin is an extremely capable PhD who worked on this across months; i.e., this was a major undertaking. The good news is that large parts of it are probably easily reusable -- by Martin ;-) Can we tempt him with beer to build a purdie one for Zope too? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
