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: 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 normal ZODB and some filesystem source control ZODB then you would have the source control
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 )
[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 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 normal ZODB and some filesystem source control ZODB then you would have the source control synchronization problem solved maybe? http://dev.zope.org/Wikis/DevSite/Projects/ZEOReplicatedStorage/FrontPage ___ 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 )
