- Zope-Dev - Zope lists

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

'selection' types question
by Brown, Brian 23 Sep '99

23 Sep '99

I was trying to figure out how to use the types 'selection' and 'multiple selection' and found the following: In <zope dir>/lib/python/ZClasses/Property.py, the following code shows that these type should result in an HTML Select box, if t=='selection': return ('''  <select name="%(id)s">  <option  SELECTED ></option>  </select>  No value for %(id)s ''' % p ) return '' ...but I couldn't figure out how to get any data in it. Then I found in <zope dir>/lib/python/OFS/PropertySheets.py: if type in ('selection', 'multiple selection'): if not value: raise 'Bad Request', ( 'The value given for a new selection property ' 'must be a variable name<p>') prop['select_variable']=value if type=='selection': value=None else: value=[] setattr(self, id, value) This told me that I should be putting a variable name for the value, and that worked fine. The problem them comes with 'multiple select' boxes. Nothing displays, and I think that is due to there being no analog for the first code snippet above. Can someone with more Zope Zen than I confirm this? I think it's a bug, and if so I'll put it in the Collector. btw, this is released Zope 2.0.0 on linux, source release. Thanks! Brian

1 0

Re: [Zope] Re: [Zope-dev] [Zope] Barriers to Zope popularity
by Kevin Dangoor 23 Sep '99

23 Sep '99

-----Original Message----- From: Evan Simpson <evan(a)4-am.com> To: Brian Lauer <fozbaca(a)yahoo.com> Cc: zope(a)zope.org <zope(a)zope.org>; zope-dev(a)zope.org <zope-dev(a)zope.org> Date: Thursday, September 23, 1999 3:52 PM Subject: Re: [Zope] Re: [Zope-dev] [Zope] Barriers to Zope popularity >Brian Lauer wrote: > >> From my experience of trying to intrest co-workers in >> Zope there were 2 problems. >> >> 1. Python - they don't know python, but might be >> willing to learn if it wasn't for 2... > >Not really necessary, but helpful, and quite valuable in its own >right... I agree. You can do a whole lot without using Python. For someone who knows how to use a programming language, picking up python is probably not going to be too difficult. >> 2. ISP/Web Hosting companies don't sopport Pyhton as a >> cgi enviroment or Zope. > >If the latter, check Zope.org's downloads for nice complete binary >distributions of Zope complete with built-in Python. If you can do CGI >on your ISP, you can do PCGI with Zope. [some snippage above] One caveat: I have found that many hosting companies are not keen on the PCGI way of doing things, because it permanently sucks up memory, etc. In looking at hosting companies, I found that to be a bigger issue than running Python. (I thought most hosting companies provided Python already). Still, I think Zope is powerful enough to easily justify a switch in hosting companies (which is not really *that* big a deal for many configurations). In fact, I *did* switch hosting companies so that I could use Zope. Kevin

1 0

Re: [Zope-dev] [Zope] Barriers to Zope popularity
by Brian Lauer 23 Sep '99

23 Sep '99

>From my experience of trying to intrest co-workers in Zope there were 2 problems. 1. Python - they don't know python, but might be willing to learn if it wasn't for 2... 2. ISP/Web Hosting companies don't sopport Pyhton as a cgi enviroment or Zope. Very few, from my experience, want to switch ISP/Web Hosting for something they have not tried in a new language. Don't take these comments to mean that I don't like Zope I love it but can't justify going with an untrusted ISP/Web Host. I don't know the solution to this one. Any help would be appreciated. Maybe what effect adding Zope, along with Apache, would have for the ISP/Web Host. Technicaly do they have anything to worry about or is they general lack of python experience the only factor. Any ideas??? ===== ------------------------------------ Brian M Lauer <mailto:fozbaca@yahoo.com> <http://w3.one.net/~fozbaca/> <ftp://ftp.one.net/pub/users/fozbaca/> __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com

2 1

RE: [Zope-dev] Barriers to Zope popularity: Part 1: wysiwig editi ng
by Paul Everitt 23 Sep '99

23 Sep '99

I think the *approach* of the current Zope management environment has a lot of things going for it: o All functionality is controlled by the server o Not just that, but the management is controlled by *individual* applications (e.g. Indigo Networks uses Flash to control Zope) o You can sit down anywhere in the world and log into Zope o The management screen is "programmed" in a clear-text definition With that said, I know there are some _severe_ drawbacks: o It is an unproductive environment o The TEXTAREA is awful for real editing o No convenient way to get local data to remote server There have been some proposals, namely (a) integrating with some specific tool like FrontPage or Dreamweaver, or (b) creating our own management environment. Both of these are bad ideas for one simple reason: the best tool is _your_ tool, meaning you'll never make a majority of people happy. To date our approach has been to support the standards (namely: FTP, WebDAV, Netscape Publishing, converting to an HTML-like syntax) that makes integration with _all_ tools more feasible. I'm increasingly convinced this will only work at a minimal level: none of them can expect to capture a sufficient amount of the dynamic capabilities of Zope. There's just an impedance mismatch. Thus, I'm drawn back to keeping the advantages of the current approach while trying to address some of the productivity losses. So, here's my suggestion, and I consider it a challenge to the Zope community at large to do a prototype. I've tinkered enough over the last two months to realize it is feasible, I'm just not smart enough to make much progress. Imagine a management environment that: o Kept everything good about the current Zope "IDE" o Was cross-platform o Completely controlled by the server, or optionally controlled locally o 100% compliance for advanced standards such as: - XML, CSS2, XSL, RDF, latest JavaScript, etc. o Contained an embeddable, scriptable editing widget with both plaintext and wysiwyg modes o Had an XML-based UI language containing platform-native tree widgets, tabbed dialogs, pop-up modal dialogs, object-defined menus, right-click menus, etc. o Facility for trusted-scripts to access local filesystem Given this "platform", a management environment could be constructed with some of the following improvements: o A real, HTML-oriented editing box, perhaps with some DTML-aware "smarts" o A collapsible/expandible view of the object system that _didn't_ go to the server on each click o etc. I'm talking, of course, about Mozilla. I've been following it very closely for the last few months, downloading the daily builds probably three times a week on average. It's legit, it has a LOT of energy behind it, and most of all, it's the best shot to keep the strengths of the current approach while significantly improving the productivity. In fact, the same tool, with two different modes/views, can appeal to both the content manager and the developer. My challenge: go tinker with some prototypes. Write some XUL files that populate a tree widget with an RDF source retrieved from a DTML method. Create a real tabbed right-frame using the tabbed dialog. Create alternatives to manage_menu and manage_main that send back XML and CSS2 to cut the http response size in half and significantly improve the layout. For a small glimpse of what you can do with Mozilla: http://204.107.76.15/pub/ --Paul

2 1