Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control

2001-09-25 Thread Chris Withers

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

2001-09-25 Thread Kevin Dangoor


- 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

2001-09-25 Thread Paul Everitt


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

2001-09-25 Thread Chris Withers

 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 )