Re: [Zope-dev] DISCUSS: Community checkins for CVS
Paul Everitt wrote: > At last, the announcement I've been dying to make. After much > deliberation -- meaning, I've procrastinated for too long :^) -- I'm > pleased to announce our approach for opening the CVS repository to > community checkins. Cool, at last! > http://dev.zope.org/CVS/Contributor.pdf This says 'you must indicate your agreement to the term below'; shouldn't it be 'terms'? Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
Martijn Faassen wrote: >> http://dev.zope.org/CVS/Contributor.pdf >> > > This says 'you must indicate your agreement to the term below'; shouldn't > it be 'terms'? Uhh...well...yes! I'll make the change. I'm waiting for news back from the lawyer about provisions for handling patches. I'll then post a new rev of the materials. Does anyone think this is close enough that I can go ahead and get the bootstrap group (under ten, selected by us) going? I'd like to avoid making them sign and mail an agreement, then do it again if there's substantive changes. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
Paul Everitt wrote: > > Does anyone think this is close enough that I can go ahead and get the > bootstrap group (under ten, selected by us) going? I'd like to avoid > making them sign and mail an agreement, then do it again if there's > substantive changes. Yup :-) Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control
"Jay, Dylan" wrote: > > > Zope looks nice but I found it has two potential problems. > > > > 1. WYSIWYG editing ZPT, WebDAV, etc > > 2. Source control (by ClearCase) Well, I just used FS-based CMF skins and python Products maintained with CVS to control the 'code'. I don't believe 'data' should ever be put under the kind of source control you're talking about here... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] RE: Dreamweaver, Webdav and PUT.
> I discovered that if I define the PROPFIND method on the
> LockNullResource class as follows:
>
> def PROPFIND(self, REQUEST, RESPONSE):
> """Retrieve properties defined on the resource."""
> self.dav__init(REQUEST, RESPONSE)
> cmd=davcmds.PropFind(REQUEST)
> result=cmd.apply(self)
> RESPONSE.setStatus(207)
> RESPONSE.setHeader('Content-Type', 'text/xml; charset="utf-8"')
> RESPONSE.setBody(result)
> return RESPONSE
>
> then the dreamweaver PUT works perfectly. I don't know enough about
> Webdav to know if this is a satisfactory fix or not, but it seems to
> work for me. The collector is down currently but I will put it in when
> it is back up unless others advise me not to.
Thanks Terry - I've checked this in for 2.4.2.
Brian Lloyd[EMAIL PROTECTED]
Zope Corporation www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control
- Original Message - From: "Jay, Dylan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 24, 2001 11:01 PM Subject: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control > > -Original Message- > > From: Kenichi Sato > > Sent: Monday, 24 September 2001 5:49 PM > > To: djay > > Subject: Barriers to Zope popularity: Part 2: source control > > Zope looks nice but I found it has two potential problems. > > > > 1. WYSIWYG editing > > 2. Source control (by ClearCase) > 1. I have not used Zope Page Templates but these are supposed to solve the > wysiwyg problem. They are an alternative to DMTLDocuments. They allow for > much better seperation of code and presentation. Get you graphics people to > use webdav to edit the html with whatever editor they want and the coding > people argment the html rather than rip it appart. > http://www.zope.org/Documentation/Articles/ZPT1 I think ZPT rocks. It's an excellent system... and combined with WebDAV or FTP (as you mention) it does solve the WYSIWYG problem. > 2. Hasn't really been solved. There are sort of attempts that work now with > CVS (I havn't tried it) > http://www.zope.org/Members/sspickle/ZCVSMixin Source control for through the web Products has been tricky. But, the proposed Component architecture is supposed to: 1) Make it easier than ever to write file system-based Products that can be pieced together and configured through the web 2) Perform some amount of unification between through the web and filesystem development (though I haven't seen much detail about that) For larger development projects, it's probably wise to do them in the filesystem. If you do that, you'll get access to all of your favorite tools (editors, source control, etc.) Kevin ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control
I'd like to add some misinformation...errmm, comments. :^) On the version control side, you're quite right, we're still behind on it. There _are_ some ways to get there, if you try hard enough. But that's unacceptible. There are two things long term that need to be done: filesystem synchronization and version control. The former is a project to make it possible to represent and perhaps round-trip Zope data in a way friendly filesystem tools and patterns. This obviously includes SCM systems like ClearCase. We've had, at our Friday jam sessions, a couple of proposals on this. So far it's simply provoked rigorous discussion but not a lot of consensus, as balancing the competing goals is harder than it sounds. I was talking with Jim yesterday over lunch about this, and whether the new component model would put filesystem synchronization in its scope. The short answer is, not in the first cut. It will certainly make filesystem synchronization a lot easier, but we need to get it out the door and tackle filesystem syncing later. Regarding version control...this is something that has been burned into our skulls in recent RFPs that we've responded to. It's the number one thing we at ZC need to address to be more competitive in CMS bids. So far the goals and use cases of DeltaV seem to best describe what we're currently thinking: http://www.webdav.org/deltav/ http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt http://www.webdav.org/deltav/scenarios/scenarios-00-1.htm Note that this is for Zope itself to have a model for version control. Filesystem sync is the most obvious way to interface to a separate SCM system. However, _if_ Zope adopted a repository model, it's conceivable that Zope could have an implementation of the repository that used an external system. _Please_ understand that this is all hand-waving right now. But I'm on the hook to incept versioning, so it's informed hand-waving. :^) --Paul Jay, Dylan wrote: >>-Original Message- >>From: Kenichi Sato >>Sent: Monday, 24 September 2001 5:49 PM >>To: djay >>Subject: Barriers to Zope popularity: Part 2: source control >> >> >>Dear Mr. Jay, Dylan, >> >>I am Ken Sato, a manager of software development projects. I'm now >>taking a look at Zope as a tool to publish project related >>information internally. >> >>Zope looks nice but I found it has two potential problems. >> >> 1. WYSIWYG editing >> 2. Source control (by ClearCase) >> >>Then, I found that you pointed out exactly same things in the >>zope-dev mailing list. >>(http://lists.zope.org/pipermail/zope-dev/1999-September/001602.html) >> >>Because the post was two years ago, I wonder if you have already >>solved the above problems. It would be very helpful for me if you >>could give me some information on this issue, please. >> > > Hope you don't mind me CC'ing this to zope-dev. I still see both these > issues as important and still see the lack of progress towards Zope working > well in traditional development environments being a real outage. Plus > others may have different opinions about the current state of affairs > > 1. I have not used Zope Page Templates but these are supposed to solve the > wysiwyg problem. They are an alternative to DMTLDocuments. They allow for > much better seperation of code and presentation. Get you graphics people to > use webdav to edit the html with whatever editor they want and the coding > people argment the html rather than rip it appart. > http://www.zope.org/Documentation/Articles/ZPT1 > > Personally I like DTML and back then I did suggest a way DTML could used in > a similar way to Page Templates (basically have a view mode of a DTML > document that incorparates the rendered content as well as the DTML code > such that when the page is edited and saved back, it will save all the > changed parts back to the where they came from, i.e. the different > DTMLMethods that made up the page). but like most of my ideas I din't have > the ability or time to implement it. > > > 2. Hasn't really been solved. There are sort of attempts that work now with > CVS (I havn't tried it) > http://www.zope.org/Members/sspickle/ZCVSMixin > This > > but there are proposals that will better solve this problem, but no > implementation on the way that I can see. > The problem is really one of synchronization. You want two different > representations that are both kept upto date. One for zope to use, one for > all the reasons we have things under source control. You may or may not want > control of when the synchronization occurs. > > Here are some related proposals > > http://www.zope.org//Wikis/DevSite/Proposals/SynchronizationMechanismZCVSMix > in > > http://www.zope.org/Wikis/DevSite/Proposals/SynchronizationTab > > http://www.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst > em > > I also see a lot of parallels with the work going on with ZODB replication. > If you had replication between a
Re: [Zope-dev] DISCUSS: Community checkins for CVS
> Does anyone think this is close enough that I can go ahead and get the > bootstrap group (under ten, selected by us) going? I'd like to avoid > making them sign and mail an agreement, then do it again if there's > substantive changes. Go for it. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
OK, a response. Sorry for the delay. First, I'll change the part of the introduction that says: "Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her." ...to say: "Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her, or that she has verified that the contributed code violates no rights." Which means that we're going to take you up on your suggestion for encouraging small patches. I just added this to the FAQ: 8) Does someone have to jump through all these legal hoops just to submit a small patch? The contributor agreement certainly is a heavy process for someone that wants to make a small contribution, such as a patch. These contributions are just as important to the health of an open source project as major code work. Thus, Zope should encourage patch contributions, not create an enormous disincentive. At the same time, integrity of the code base needs to be maintained. For small contributions, simply supply them through a communications channel such as the bug tracker or the mailing lists. Alternatively, contact a committer or ZC directly. A committer will then review the patch and assume the legal issues of committing it themselves. Likely they will contact the patch submitter and get a confirmation that the patch can be used. The committers will have some guidelines on recognizing when it is reasonable to accept a patch. It should be clear when something has little basis for being deemed intellectual property, versus a major change with advanced algorithms. In your note, you mentioned: I suppose that I could assign them those rights, but personally I find that idea repugnant since I don't believe in intellectual property . (Hmm. If I put my stuff in the public domain, how would that play in?) Repugnancy aside :^) your second comment is on the mark. It isn't so much that you need to assign and "lose" ownership. Rather, the committer needs to ensure that they aren't violating your rights. We'll probably work up some boilerplate such as, "I'm going to commit your patch to Zope. It's going to be available under the ZPL and the joint ownership model of the Zope Contributor Agreement. Please respond agreeing that you understand the ZPL, the joint ownership model, and allow this contribution under these terms." How does that sound? --Paul R. David Murray wrote: > On Thu, 20 Sep 2001, Paul Everitt wrote: > >>So, let's begin what I'm sure will be a lively and illuminating >>discussion. :^) >> > > First, would it be possible to put up a copy of the Contributor > Agreement in html format? If you feel the only legal version for > signing is the PDF one fine, but it would be a lot easier for people > to check it out if there is an html version to read. > > Second, I suppose you should be aware of my biases before reading > anything more. I don't believe in intellectual property, either > copyright or patent. On the other hand, they are currently the > law of the land; and, within what seems to me to be fair use kinds > of standards, I try to respect copyrights while encouraging people > to use vehicles that make use of as few of the restrictions imposed > by copyrights and patents as possible. (You will guess that I am > *not* a fan of the GPL, though I consider it far superior to a > traditional copyright .) Also, I am not a lawyer and don't > pretend to be very up on the subtleties of copyright law, so my > concern may turn out to be naive. > > I very much like the intent stated in the Introduction, that > of getting maximal rights into the hands of both the contributors > and Zope Corporation to do things in the future with the code > without having to get an endless set of sign-offs. > > However, I have a concern about the Agreement that isn't covered > in the Introduction or the FAQ. I'm worried that the Agreement > may exclude us from some of the benefits of the bazaar model of > open source development. > > My key concern is summed up in this statement from the Introduction: > > "Essentially, a committer signs an agreement stating that all >code that the committer submits has been created by her." > > The actual agreement does *not* say this, but "essentially" it does > require it, since the things the committer has to swear to in > submitting the code are very difficult to swear to unless he or > she is the author of the code. > > Now, I have only contributed small amounts of code to Open Source > projects so far. But I'm sure there are a lot more people out there > who have "only contributed small amounts" than those who have contributed > whole modules, and that there are even fewer people who do so much > work that jumping through these kinds of legal hoops, and agreeing to > a certain amount of liabilit
[Zope-dev] DISCUSS: Community checkins for CVS
> Does anyone think this is close enough that I can go ahead and get the > bootstrap group (under ten, selected by us) going? I'd like to avoid > making them sign and mail an agreement, then do it again if there's > substantive changes. Have fun with it. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Addressing client-side trojan problem
Shane Hathaway <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > Personally, I think this really should be an integration issue instead of a > > Zope issue: use a front-end proxy server (i.e. Squid) and set up ACLs to > > prevent this... > > > This hasn't been fixed because it's not well understood. Javascript can > POST an invisible form, AFAIK. The problem occurs on the browsers of > users who are *already authenticated*. It has nothing to do with Zope > or any server software, really. I recently saw a _very_ interesting description of how capability-based distributed computing (and the Principle of Least Authority) is used to address vulnerabilities to client side trojans, viruses, etc. I think the approach may apply to the web situation. "Capabilities" are a signficant, fairly established idea in the realm of distributed operating systems, but are not very familiar more generally. This description is by far the most approachable i've seen (and perhaps, the first i've understood:) - i highly recommend looking it over. It's in a substantial overview of the very nifty looking scripting language, E, which is specifically designed to provide secure, reliable, manageable distributed computing scripting. The relevant bits are at: http://www.skyhunter.com/marcs/ewalnut.html#SEC41 A page or two down it describes the ramifications for things like computer viruses, if you want to skip straight to the punch. That part doesn't quite capture the way i expect we would use it to address the client-side trojan problem. Offhand, i suspect we could use these principles with Zope cookies and capability-specific roles. This approach provides a means for implementing something along the lines that chris petrilli was suggesting a while back, with incremental, rather than either/or, role privileges. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
On Tue, 25 Sep 2001, Paul Everitt wrote: > Repugnancy aside :^) your second comment is on the mark. It isn't so > much that you need to assign and "lose" ownership. Rather, the > committer needs to ensure that they aren't violating your rights. > > We'll probably work up some boilerplate such as, "I'm going to commit > your patch to Zope. It's going to be available under the ZPL and the > joint ownership model of the Zope Contributor Agreement. Please respond > agreeing that you understand the ZPL, the joint ownership model, and > allow this contribution under these terms." > > How does that sound? Sounds like a workable process, if an email acknowledgement is enough. Perhaps you could also make some such language part of a click through during the process of submitting a patch to the server? I think for myself just labeling things as public domain will work fine, but I know that won't work for everyone. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Addressing client-side trojan problem
Ken Manheimer wrote: > Shane Hathaway <[EMAIL PROTECTED]> wrote: >>This hasn't been fixed because it's not well understood. Javascript can >>POST an invisible form, AFAIK. The problem occurs on the browsers of >>users who are *already authenticated*. It has nothing to do with Zope >>or any server software, really. >> > > I recently saw a _very_ interesting description of how capability-based > distributed computing (and the Principle of Least Authority) is used to > address vulnerabilities to client side trojans, viruses, etc. I think the > approach may apply to the web situation. > > "Capabilities" are a signficant, fairly established idea in the realm of > distributed operating systems, but are not very familiar more generally. > This description is by far the most approachable i've seen (and perhaps, > the first i've understood:) - i highly recommend looking it over. It's > in a substantial overview of the very nifty looking scripting language, E, > which is specifically designed to provide secure, reliable, manageable > distributed computing scripting. The relevant bits are at: > > http://www.skyhunter.com/marcs/ewalnut.html#SEC41 Very interesting. Thanks for the link. I read Marc's whole description of capability-based security: http://www.skyhunter.com/marcs/capabilityIntro/ It makes a lot of sense. In situations where it is possible, I am inclined to agree that capabilities are the most secure approach to writing software. I don't know how to apply capability-based security to the trojan problem, but I'm thinking about how it could be integrated into Zope. Perhaps there could be objects that declare themselves to be "capabilities"; that is, any object that can reach them is allowed to call any method of them. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
On Tue, 2001-09-25 at 09:19, Paul Everitt wrote: > > We'll probably work up some boilerplate such as, "I'm going to commit > your patch to Zope. It's going to be available under the ZPL and the > joint ownership model of the Zope Contributor Agreement. Please respond > agreeing that you understand the ZPL, the joint ownership model, and > allow this contribution under these terms." Might it make sense to require (or perhaps just request) that the confirmation email be signed with a public key? Just my $0.02, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
On Tue, 2001-09-25 at 05:27, Paul Everitt wrote: > > Does anyone think this is close enough that I can go ahead and get the > bootstrap group (under ten, selected by us) going? I'd like to avoid > making them sign and mail an agreement, then do it again if there's > substantive changes. Full speed ahead, and damn the torpedoes! Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Create directory in LocalFS
Jeff Nielsen / UgoFast writes: > Can anyone tell me how to create a subdirectory programmatically under a > LocalFS folder? I have a LocalFS folder called images. When I add a new > promoter to my site, I'd like to automatically add a directory that > would hold that promoter's images. If the promoter's ID number is 187, I > want to create a subdirectory '187' under images/Companies/100. Can you do it in ZMI? If yes, look at its code. It does it programmatically! Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Vulnerability in Zope
On Sun, 2001-09-23 at 17:00, Andy McKay wrote: > > [snip] > Haven't we been complaining about this automatic appending of tracebacks for > a while? To me this is what log files are for but Im not sure what this > guy is on. I wouldnt count this as a "security vulnerability". Hmm. It's 'side-band' information. Assuming that a cracker could get arbitrary code to run on the server through some other vulnerability (say a buffer overflow in some daemon), this information could be exploited to make their attack on the Zope installation more targeted. All this is assuming that the cracker in question is very clever, and has something in mind that is more subtle that simply shutting the server down, because if they can get arbitrary code to run on the server, it's toast anyway. An example of a subtle attack would be re-writing an e-commerce product so that any credit-card information would get silently copied and forwarded elsewhere. In short, the principle here is that *given* that some other vulnerability could give a cracker access to the server in some way, you still don't want to give them any more information on the server configuration than you have to. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control
> -Original Message- > From: Chris Withers [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 25 September 2001 10:59 PM > To: Jay, Dylan > Cc: '[EMAIL PROTECTED]' > Subject: Re: [Zope-dev] RE: Barriers to Zope popularity: Part > 2: source > control > > > "Jay, Dylan" wrote: > > > > > Zope looks nice but I found it has two potential problems. > > > > > > 1. WYSIWYG editing > > ZPT, WebDAV, etc Yes, I pointed these out as the solution in my email. > > > 2. Source control (by ClearCase) > > Well, I just used FS-based CMF skins and python Products > maintained with CVS to > control the 'code'. I don't believe 'data' should ever be put > under the kind of > source control you're talking about here... The discussion was about over-the-web code such as DTML, ZPT, ZClasses. Many sites (including most I've done) are mainly over-the-web code. I also agree that 'data' should not be source controlled (although I could see some content management applications where this distinction could get kind of murky). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control
> > > > 2. Source control (by ClearCase) > > > > Well, I just used FS-based CMF skins and python Products > > maintained with CVS to > > control the 'code'. I don't believe 'data' should ever be put > > under the kind of > > source control you're talking about here... > > The discussion was about over-the-web code such as DTML, ZPT, ZClasses. Many > sites (including most I've done) are mainly over-the-web code. Why? If you want to edit 'over the web' (you mean 'over the net'), then FTP into the box and edit the FS-based skins that way. Ange-FTP in EMACS rules :-) If you need to quickly make a change, use the skin customisation feature. cheers, Chris PS: Anyone using DTML or ZClasses for this kind of thing in this day and age should be shot ;-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: sourcecontrol
On Tue, 2001-09-25 at 18:16, Chris Withers wrote: > > PS: Anyone using DTML or ZClasses for this kind of thing in this day and age > should be shot ;-) Personally, I think all extremists and fanatics should be shot. Oh yeah, I forgot, ;-) Michael. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Create directory in LocalFS
Dieter, I don't think I'm understanding you. I want to create the subdirectory programmitcally inside a DTML Document. Are you suggesting something like: or (Neither one works. I tried them.) Do I need a more recent version of LocalFS? I'm using v0.9.6 (I think). It doesn't appear that v0.10.1 addressed this kind of thing. Jeff -Original Message- From: Dieter Maurer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 2:29 PM To: Jeff Nielsen / UgoFast Cc: [EMAIL PROTECTED] Subject: Re: [Zope-dev] Create directory in LocalFS Jeff Nielsen / UgoFast writes: > Can anyone tell me how to create a subdirectory programmatically under a > LocalFS folder? I have a LocalFS folder called images. When I add a new > promoter to my site, I'd like to automatically add a directory that > would hold that promoter's images. If the promoter's ID number is 187, I > want to create a subdirectory '187' under images/Companies/100. Can you do it in ZMI? If yes, look at its code. It does it programmatically! Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] making wo_pcgi only rebuild when necessary.
I've got Zope code and installation pretty heavily automated here, but one thing that takes a while is that after a cvs update, I have to do a complete wo_pcgi on each box to make sure everything's up to date. This forces everything to be rebuilt. Is there anything that could be done to make it only rebuild what's needed? Anthony ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope on Windows: enhancements proposed
I guess its because Zope installs into the same directory as the service name. So I always pick a name starting with Zope, so my installation is say ZopeTest and my service is Zope (ZopeTest) :) - Original Message - From: "Adrian Hungate" <[EMAIL PROTECTED]> To: "'Andy'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, September 24, 2001 11:26 PM Subject: RE: [Zope-dev] Zope on Windows: enhancements proposed > I have to disagree about the Zope (%s), I have been known to run 2 or 3 Zope > services, for different instances, and I always know that I can find them > all huddled together at the bottom of the Service Manager - Very useful. > > Adrian... > > -- > Adrian Hungate > Try Zope - > http://www.zope.org > - You might like it. > If you do, try my Zope products - > http://www.zope.org/Members/haqa > - You might like them too! > > > -Original Message- > From: Andy [mailto:[EMAIL PROTECTED]] > Sent: 25 September 2001 05:23 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Zope-dev] Zope on Windows: enhancements proposed > > > > We'd like to propose that the service distributed with Zope move over to > > using our code. > > Great, Im really looking forward to an improved Windows installation. But > lets get it out there play with it before anything major happens like > shipping Zope with it :) > > > As a separate issue - we're curious about the naming of the Zope > installation > > - why is it called WebSite (and the Zope service "Zope (WebSite)")? The > name > > clashes with another product that's fairly well-known in the windows > > community originally from O'Reilly: > http://www.oreilly.com/software/index.html > > ... and since Zope is a fairly distinctive name ... > > It is annoying but Zope wins there because OReilly isnt making WebSite > anymore. Its just a name, I find the Zope (%s) bit more annoying than > anything :) > > > ps. happy to put this up as a project if required. > > Thats probably a good idea. What about other issues such as install and > removing service easily later, STDERR logging not going to /dev/null, lack > of start menu icons and other windows issues... > > Cheers > -- > Andy McKay > > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Acquisition, __getattr__ and making a Proxy/Symlink class
Hi folks,
I'm having some troubles trying to develop a
particular zope object and would really appreciate a
bit of help. I'll explain what I'm trying to do:
What we have is a tree of nodes rooted in a folder
(excuse my ascii art) like so:
+ DocumentRoot (folder)
+ a
+ b
+ c
+ d
+ e
+ e
+ f
+ g
+ X (proxy, pointing to 'e')
Here [a-g] are our node objects, and X is a
proxy-object. The proxy-object is intended to behave a
bit like a sybolic link with a few extra features.
I have looked at Shane Hathaway's Symlink product,
which does the linking job just fine. It allows us to
create a proxy that behaves just like the target, but
we also need the proxy-object to have it's own
attributes and methods.
In the above hierachy, the desired way of finding an
attribute of the proxy 'X' goes something like:
- look in the proxy object ('X')
- if not there look in the proxy target ('e')
- (maybe) if still not found acquire from aq_parent
('g')
- otherwise raise AttributeError
I guess we are wanting X to behave as though it were a
child of the object it links to, so X always behaves
as though it were X.__of__(e) (and possibly also a
child of g, ((X o g) o e) or ((X o e) o g) if not too
complicated).
I have tried hooking __getattr__ and have a hard time
avoiding recursion; I have taken a look at the
ever-productive Shane Hathaway's TransparentFolder
product as well but I think I am let down by my lack
of understanding of the particulars of acquisition.
Can anyone shed some light on how i might do this? All
objects under the DocumentRoot will be derived from
one of our base classes, so if we need to override
__getattr__ as per TransparentFolders it can be done
easily.
Cheers
__
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger.
http://im.yahoo.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
