September 1999 - Zope-Dev

Barriers to Zope popularity: Part 2: source control
by Jay, Dylan 25 Sep '99

25 Sep '99

Having been using Zope for the past 8months or so I see two potential reasons as to why more people at my work havn't taken to Zope. Barrier 1: WYSIWYG editing (see previous mail) Barrier 2: Source Control. Initially I was concerned about the whole ODB thing. Now I trust it to some extent however source control is more than just backup or versioning. Its about tracablity in a development process. I work with a software development group and all our code is under source control and any work done can be traced to a person and a time. Zope can't do this. Any file based web server allows this (however then you don't get the distributed editing etc). Possible solution: Allow some sort of hooks into the versioning mechanism. What would be nice is in the case of a save or undo of a version, those changes could be mirrored in source control. How? - Some sort of export on changes. This goes into a designated dir that represents the site. A script then gets run that does the equivilent commit into the soruce control program. Different adapters with different scripts for CVS, ClearCase etc. - Have somesort of folder/XML format? Instead of just one big XML file like export gives you then maybe a folder heirachy with special files to represent the properties of Zope folders. This would allow for much better diffs in the source control prog. - Allow imports from such a format when you need to reverse changes or do something funny from source control. - I think only restricting this to versions is ok because non versioned changes might pickup all the changes that occur with user data, counters etc. And with a policy that all changes have to be through a version (is this enforcable in zope???) then all is well. All the "user" data changes such counters etc could be accounted for in source control by doing a periodic whole site export and having this committed to the source control system thus ensuring that whats in source control is a reasonably accurate representation of the site. I know there are many more barriers but these are two I've been thinking a lot about and I think are quite important.

3 2

RE: [Zope] Re: [Zope-dev] RE: [Zope] Barriers to Zope popularity: Part 1: wysiwig editing wysiwig editing Part 1: wysiwig editing wysiwig editing
by Jay, Dylan 25 Sep '99

25 Sep '99

> -----Original Message----- > From: Martijn Pieters [mailto:mj@antraciet.nl] > Sent: Thursday, September 23, 1999 22:09 > To: Dody Gunawinata; Phil Harris > Cc: Jay, Dylan; zope(a)zope.org; zope-dev(a)zope.org > Subject: [Zope] Re: [Zope-dev] RE: [Zope] Barriers to Zope popularity: > Part 1: wysiwig editing wysiwig editing > > >Much of the documentation is designed with *advance* > developers in mind. > >It's time for Zope for Dummies. > > > >Dody > > What many people forget here is that Zope is a Web > Application Platform. It > is, first and foremost, designed as a framework for applications. > > All the DTML Methods and Folder objects and whatnot, are > standard objects > to help you design an interface, they are part of and build > upon the Zope > framework. Together with the ZODB, security, the web interface, the > marshalling of variable types and RDBMS integration, Zope > makes one heck of > a Web Application Platform. > > Zope was designed for Web Application Developers, not designers. The > documentation follows this design. I actually feel that > dummies should stay > away from Zope. Frontpage is for dummies. I disagree. I believe the ideal place Zope could end up is as being something that was as simple to use as frontpage and as powerful as ... well as it already is. I'm not saying that the "simpler" users should be able to as powerfull things as "programmer" type users can but it should not be unaccessable to them. They should be able to edit and add basic documents. I don't want to be the only one who does all the editing of documents with zope. I think the solution I suggested with embedding the DTML inside an expanded (rendered?) document is very workable. It would allow a novice user to edit a DTML document that is potentially in many parts without destroying the DTML.

3 2

Using the SiteAccess Product for Virtual Hosting
by Evan Simpson 25 Sep '99

25 Sep '99

Now that I've thrown the first version of SiteAccess out into the wide world, and had a rest, I suppose a bit of documentation is in order. Here's an example of how virtual hosting is supposed to work with this Product. I actually use a PythonMethod for this, for obvious reasons, but I suspect many people will not want quite that much alpha code in their life at once, so I'll present (untested) DTML Method examples. In the Zope root, I place a DTML Method called RewriteRule with the following body: <dtml-with "_(site = {'www.tk.com': '/tk', 'shop.tk.com': '/tk/shop', 'www.other.org': '/other'}.get(HTTP_HOST, _.None) )"> <dtml-if site> <dtml-call "REQUEST.set_path(site + PATH_INFO)"> <dtml-call "REQUEST.set('SiteRootURL', 'http://'+HTTP_HOST)"> </dtml-if> </dtml-with> If I wanted IP:PORT based rewriting, I'd use: <dtml-with "_(site_pair={'10.0.0.10:80': ('/tk', 'www.tk.com'), ...}.get(HTTP_SOCKET_IP+':'+HTTP_SOCKET_PORT, None) )"> <dtml-if site_pair> <dtml-call "REQUEST.set_path(site_pair[0] + PATH_INFO)"> <dtml-call "REQUEST.set('SiteRootURL', 'http://'+site_pair[1])"> </dtml-if> </dtml-with> In each of the Zope folders '/tk', '/tk/shop', and '/other', I add a SiteRoot object. I give them descriptive titles, but they don't really need any configuring. In the Zope root, I choose 'Set Access Rule' from the drop-down list, and type 'RewriteRule' into the form and OK it. At this point, any request with HTTP_HOST 'www.tk.com' will be rewritten to go through folder '/tk' first, but won't include it in URLn's or absolute_url() calls. I lie. This is what *will* happen when the product is done. At the moment, what you'll get is an AttributeError complaining that the REQUEST object doesn't have an attribute 'set_path', because I haven't written it yet. Also, SiteRoots don't do anything but print a diagnostic message when traversed. I could use some design help. Would REQUEST.set_path be the Right Thing, here? Probably, and it's not my main concern. I'm much more worried about how exactly SiteRoots should accomplish their tasks. After digging through the Zope source, it seems that *at least* REQUEST.steps and REQUEST['URL'] need to be changed, and absolute_url re-implemented, but there's a whole tangle of twisty little CGI and Zope variables, all almost alike, holding bits and pieces of the URL. Frankly, I think it would be valuable if all that were cleaned up, but I don't feel like I know enough to do it right.

1 0

Re: [Zope] Barriers to Zope popularity: Part 1: wysiwig editing wysiwig editing editing wysiwig editing
by Martijn Pieters 24 Sep '99

24 Sep '99

At 21:35 23-9-99 , jonathon wrote: >On Thu, 23 Sep 1999, Martijn Pieters wrote: > > >At 03:50 23/09/99 , Dody Gunawinata wrote: > >>I think "DOCUMENTATION" is more than anything else, the greatest barrier > >>to people using Zope. > << paragraphs deleted >> > >>Much of the documentation is designed with *advance* developers in mind. > >>It's time for Zope for Dummies. > > >What many people forget here is that Zope is a Web Application Platform. It > >is, first and foremost, designed as a framework for applications. > > That doesn't negate the need for Documentation. > > >marshalling of variable types and RDBMS integration, Zope makes one heck of > >a Web Application Platform. > > True. To use a Web Application Platform, one has to know the tools. > The easy way to find out what those tools are, and how to use them, > is by going through the documentation. > > >Zope was designed for Web Application Developers, not designers. The > >documentation follows this design. I actually feel that dummies should stay > > If one is an experienced Web Application Developer, the > documentation _might_ be, but probably isn't acceptable. > > If one is supposed to manage the content on a website, and > not an experienced Web Application developer, the documentation > is at best, inadequate. > > >away from Zope. Frontpage is for dummies. > > What has Frontpage to do with Zope? They are completely different > applications. > > One other point: > Documentation can never contain too many examples. Sorry I wasn't clear. I was ranting on about the WISYWIG tools, like Frontpage. My experience is that people are overlooking the fact that Zope is not an alternative FP Server-side extensions. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | T: +31 35 7502100 F: +31 35 7502111 | mj(a)antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ---------------------------------------------

2 1

ANN: SiteAccess 0.0.1 and PythonMethod 0.1.2 Released
by Evan Simpson 24 Sep '99

24 Sep '99

SiteAccess, which is a start on Virtual Hosting support (and much more) and a minor version upgrade of PythonMethod are ready. See http://www.zope.org/Members/4am/SiteAccess and http://www.zope.org/Members/4am/PythonMethod for details. The Python Method page now has a changelog, and you should really read it before upgrading, especially if you applied the unsafety patch to PM 0.1.1

1 0

MIME Tools sends no MIME version header
by Jason Spisak 24 Sep '99

24 Sep '99

Zopsters, I've have been having a lot of trouble with people opening attatched html and other attatchments types when sent from Zope. From what I gather, Zope doesn't send a MIME version header. This prompts most mail readers to treat it as a giant glob of text. No attatchemtns. Has anyone else experienced this? I don't know anything about MIME and would love to see a patch so that Zope can send attatchements that the rest of the world can read. All my best, -- Jason Spisak webmaster(a)hiretechs.com

1 0

Barriers and wysiwyg
by Rik Hoekstra 24 Sep '99

24 Sep '99

-----Original Message----- From: Rik Hoekstra [mailto:fghoekstra@cit10.wsd.leidenuniv.nl] Sent: Friday, September 24, 1999 11:55 AM To: Jay, Dylan Subject: RE: [Zope-dev] Barriers and wysiwyg [Martijn Pieters:] > > Zope was designed for Web Application Developers, not designers. The > > documentation follows this design. I actually feel that > > dummies should stay > > away from Zope. Frontpage is for dummies. > [Jay Dylan] > I disagree. I believe the ideal place Zope could end up is as being > something that was as simple to use as frontpage and as powerful > as ... well as it already is. I'm not saying that the "simpler" users should > be able to as powerfull things as "programmer" type users can but it should not be > unaccessable to them. They should be able to edit and add basic > documents. Michael Bernstein added in another post that as a designer he needs to work visually, which is a good point. And he adds another crucial remark : in web building we wear many hats at the same time. And most application servers lump all these roles together, while Zope separates them. Many have remarked that this is the problem of communication between Zope and editors: they were made with a different mindset. Uing Dreamweaver or Frontpage (light) or whatever it is quite possible to add plain html pages and design them anyway you want. You can even manage them through the web.* Or to once more cite Jon Udell on byte.com : "It is completely feasible for a novice to download Zope, install it, and build a simple site -- even one that leverages the object hierarchy to factor out repetitive pieces -- without writing any code. And the result is 100% Web-manageable." The point is of course, that you usually do not want this. You want people who do pure and simple content management to add content, not to change layout. Much less to go programming DTML. This is what makes editing a ZOpe site difficult: once you defined behaviour (dtml methods/products) and layout, you want content managers to add content. The problem is that people want to see what they get. I think Paul's Mozilla approach is very promising in this respect. It may even turn out to be an incredible site management tool. But this will require a _lot_ of work. On the other hand I question once more whether the textarea is such a bad idea. It is especially useful if you want to have content managers also manage parts of a site, without them controlling the user interface. By contolling a site I mean adding and editing content and users, and folders and news and all sorts of other things that are not possible to add from a wysiwyg editor, which is after all just an editor... In this case (and I believe it is quite common, if only for all sorts of intranet like activities) even if you could use a wysiwyg editor, site management for dummies would still be a fragmented (and bewildering) experience. I find it most remarkable that the packages I know of (mostly web learning environments - but they are good examples: blackboard, webCT, TeleTOP etc, etc) that are meant for this type of site building and maintenance do exactly this: they keep everything browser based. I looked into the documentation of Oracle WebDB today and it is exactly what they do (including the textarea) and what they bring forward as a strong point of their product. Just one citation from their brochure: > Oracle WebDB is HTML-based. All that's needed on the client side to build and run WebDB applications and web > sites is a web browser such as Netscape Navigator or Microsoft Internet Explorer. WebDB users benefit from > quick installation, distributed deployment, and a familiar interface.[...] > All WebDB site maintenance tools are included within the site itself. There's no need to leave the site or > learn how to use another product. To add content, authorized users simply navigate to where they want to add > it, switch to Edit Mode, and use the simple interface provided." The only thing is, to repeat myself, that currently there is no such standard tool for Zope. I'm afraid some of the DC folks took this as a criticism - it was not meant like that. I do not even like wysiwyg for the most part (except for designing in which case they are indispensible). I think the Zope interfaces (from http to xml-rpc) are excellent and abundant. They are just not for dummies. What we need is a dummy web interface builder toolkit. Rik * Someone (I forgot who, but if necessary I can retrieve the URL) hacked up a perl clone of the Frontpage extensions so if necessary this should be doable for Zope as well I think. The question is just who would want that - Frontpage is terrible.

2 1

RE: [Zope-dev] Re: source control
by Michel Pelletier 24 Sep '99

24 Sep '99

> -----Original Message----- > From: Jonothan Farr [mailto:jfarr@real.com] > Sent: Thursday, September 23, 1999 8:35 PM > To: Andrew M. Kuchling > Cc: zope-dev(a)zope.org; zope > Subject: [Zope-dev] Re: source control > > > > What should Zope source code control look like? > > Actually, after thinking about this further and discussing it > with some > colleagues, I've realized that what I need isn't the ability > to store Zope > objects in a CVS repository after all. It is the ability to > use documents > already stored in a CVS repository as Zope objects. > > Ideally, what I need is a Zope product that implements the > client side of > the CVS protocol, and can allow users to check out, modify, > and then commit > changes to documents stored in a repository. This seems like > a much easier > problem to solve than storing Zope objects in CVS. > > Does anyone know of an existing or planned Zope product that > supports this > kind of functionality? If it can be done in Python, it can be done in Zope. The last part is usually more trivial than the first. -Michel > > -jfarr > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Hi! I'm a signature virus. > Copy me into your .sig to join the fun! > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (To receive general Zope announcements, see: > http://www.zope.org/mailman/listinfo/zope-announce > > For non-developer, user-level issues, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

1 0

Multi-thread and pack
by Jason Spisak 24 Sep '99

24 Sep '99

Should people be able to be using Zope while running a pack? I'm guessing no, because it doesn't work, but I just want to be clear. All my best, -- Jason Spisak webmaster(a)hiretechs.com

1 0

Re: source control
by Andrew M. Kuchling 24 Sep '99

24 Sep '99

Jonothan Farr writes: >I am considering investing the considerable time and effort to integrate CVS >version control into Zope. I am very interested in knowing if anyone else is >considering or already working on such a product. The lack of source control is a problem to me, too. In our workgroup, the source code is all in one CVS tree, and the developers are all mailed checkin messages. This is useful because it lets us keep track of what others are doing; if I notice checkins to a package such as mems.core, and my code uses mems.core, I know whether I should update immediately because of a critical bugfix, or avoid updating to avoid breaking my code at an inconvenient time, or to change my affected code. >I would also like to encourage more discussion about source control, as I >also see this as a sizeable barrier to some people's acceptance of Zope. What should Zope source code control look like? The ZODB's versioning is too fine-grained, because every little change is stored as a separate version. What you really want is to draw a circle around a given set of DTML + SQL queries + other objects, and store them as a snapshot. (ExternalMethods are tricky, because they're in source files outside the ZODB.) Vague speculation, at least for CVS support: imagine having a 'CVS checkin' tab on a folder. Clicking it would loop over the contents of the folder, exporting each object in the XML format and writing it to some preconfigured CVS working directory. After writing the files, a standard 'cvs commit' is done. That's terribly crude, and running 'cvs diff' will require reading XML to interpret the changes, but it's a start. Another idea: have a oldversions.fs which will contain older versions, so you don't bloat the main Data.fs with them. Checking in a new version then consists of copying it to the ZODB in oldversions.fs and giving it an identifier. Now add a Zope-based interface for browsing through old versions and diff'ing them. -- A.M. Kuchling http://starship.python.net/crew/amk/ "It bombards atoms with subatomic particles." "Why?" -- Dr. Lawrence and The Doctor, in "The Silurians"

2 1