[Zope] Belated Birthday!
Hey Zope Folks, Maybe I missed it, but did anyone else realize that Zope's 2nd birthday snuck by without a party?! Maybe the DC Gang are planning something based on an official ship date of some specific version, but anyhow, Happy Birthday, Zope! ** || |\/| |\/| ( \/ ) Later, Jerry S. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Zope vs. Enhydra
I agree that people should only build what they need. The nice thing about Zope being open-source is that it evolves well to its communities use cases; I would argue that Zope-based solutions would adapt to user communities that are not a bunch of software engineers working for software companies. I used to work as a developer for an R&D company and now work for a dot-com doing the same sort of work, but my priorities are very different. Zope, frankly, is a more pragmatic solution than committing to the Java platform for a variety of problems faced by those of us not working for software vendors, and I think is better suited to an open-source user community. Two particular things: One: Enhydra seems ideal if you have investment in the Java paradigm (i.e. you have Java coders in house). The thing is that Zope has a lot of strengths in the ODB that you can't get with your typical OO Java servelets combined with an RDBMS back-end. For complex relational data, the Java app server approach might make sense, but the thing that sells me on Zope is the fact that their are problem domains that are a total misfit with a relational data paradigm, like online content publishing (media sites), intranet collaboration (workflow objects associated with discussions associated with content created via content management) - not to mention the entire problem domain of XML in general. So, java app servers make sense if you meet all of the following criteria: - have data structures that are tabular, or have a small set of relations to other data - have a full-time DBA - have a full-time Testing Department (test manager, testers) and Formal Software Testing - have at least a senior Java programmer or two - Have a fairly technical project manager that understands how the app server works, in order to divide up work - Fully implement formal documentation standards, including UML, requirements & design docs, and EXTENSIVE API documentation - willingness to work on a deadline that is not as tight, putting quality always before expediency In other words, java app servers might make perfect sense for those working in an R&D company, ISV, or other vendor selling software, but it creates complexity when you want to extend this to an open development model because the learning curve is steeper, and it's easier to screw something up. If you work with limited resources, and are not building a product that is going to have an expected sale value, but rather only internal use value (i.e. you are a web company trying to get a site up versus a software company selling a $25,000 shrink-wrapped box). When in that position, you need content management built-in; you need portions (like the interface layer) to be as easy as possible (Why should one be required to compile an html file into a DOM binary - why not just use an ODB???); you also are not going to have a testing department, you will have a stricter deadline, have less technical project management, and no docs, and more employee retention problems. The attitude is get it done, with the best possible balance of doing it "right" and getting it up live. Zope fits the bill for most folks who have to work in a pragmatic world of building and constantly refining software for their own use. I'm not saying that we shouldn't have formal docs, testing, etc of software, but that some of us have to maximize quality under certain constraints that guarantee that the Java app server approach would be flawed; Zope fits (python is easy to work with, the presentation layer concepts in Zope are improving, etc). Zope also maps to open-source ideas better, because it allows for a less centralized formal development model, and the idea of constant refinement. In the future, especially in certain vertical markets (like mine, publishing), the folks that comprise your community will not be trained software engineers - they will be folks like librarians, part-time web developers, designers, project managers, and production engineers/sysadmins - and in that open source world, we need to be able to create scalable software systems, but not raise the barriers to entry to make them inhuman. Zope isn't perfect in this regard, but at least it's leaps and bounds better than the alternatives. Two: Perhaps the biggest gripe I have about the "why-not-zope" arguments is simply that they make the assumption that Zope is somehow a product, and so they complain about what it cannot do, rather than realize that zope's primary asset is a strong community and a strong, swift software process; I have seen Zope evolve quite rapidly over the last year-and-a-half; I use that as empirical evidence that Zope grows with its community member's use-cases. Gripes about things like through the web editing, cvs, etc will likely be things of the past in the not too distant future. I think Zope has some advantages over both other approaches in that it has an approach that
Re: [Zope] Zope eating CPU/RAM - how do I find the culprit?
If you are using ZSQLMethods and your database returns column names in one case (UPPER) but you reference them with another (lower) it appears that instances of SQLAlias get leaked. Brian Lloyd has put Jim Fulton's fix in the 2.2.5b release that's up on the site. We were seeing thousands of leaked instances of SQLAlias causing our memory usage to skyrocket. -jon [EMAIL PROTECTED] (Cees de Groot) writes: > Jon Prettyman <[EMAIL PROTECTED]> said: > >Are you using ZSQLMethods by any chance? > > > Yes, why? (I think I've fixed /this/ problem, but if ZSQLMethods will > cause similar behaviour I'd like to be prepared :-)) > > -- ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Zope vs. Enhydra
on 12/29/00 9:52 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > But really, has anyone had any experience with the *other* > open source Web Application Server, Enhydra? > ... > At any rate, after already being *highly* impressed and > sold on Zope - I ended up spending a little time at > www.enhydra.org and became more and more enthused. Zope has the advantages of a well-developed security strategy that allows an orderly delegation of management of subtrees of a site, an application framework that supports things like acquisition, a built-in object database and a broader range of freely-available (with source) applications such as Squishdot and ZWiki (this could change, but so far I haven't found a comparable set of freely-available servlets). Because you can do a good bit of development directly through the web and most sub-developers do not need access to the file system of the host machine, Zope is suited to dynamic sites with multiple developers working on separate site subcomponents. Enhydra offers Sun's Java Servlet 2.2 API, which is becoming popular for web application development in business, and it theoretically can be used with Cocoon, a very interesting XML publishing system/application manager implemented as a servlet (xml.apache.org/cocoon). Enhydra can serve standard web pages from the file system as well as manage servlets and it offers several strategies for embedding dynamic content in pages. However, page and servlet developers must have access to the host file system to mount the pages and servlets, and the Enhydra administrator probably needs to manage the final configuration of each servlet (you must edit the server's configuration files and restart the server). This would seem to lend itself better to the creation of applications that are relatively static once they are put in place. One interesting aspect of servlets is that they can be written in JPython or its successor, Jython, rather than Java and then compiled to Java byte code directly. Thus you can write your application logic in Python and have access to both the Java and Python code libraries. There is a useful servlet available called 'PyServlet' by Stefano Mazzocchi that will load JPython servlets from source code, allowing the source code files to be edited after installation (they will re-load then). I haven't tested this under complex or high load conditions, but it works pretty well with simple servlets using Tomcat (jakarta.apache.org) as a servlet container. Enhydra would also be expected to support this and I think this capability should increase the interest of the python community in Enhydra and the other standard Java servlet containers. Jim Harrison Univ. of Pittsburgh ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] can't change zclass meta type
Dieter Maurer wrote: > Geoffrey L. Wright writes: > > > > I can't seem to completely change a zclass meta type. When I make a > > change on the "basic" tab of the zclass, my change seems to take, and > > the new meta type is displayed in the form. > > > > But when I try to add an instance of this metatype, I still see the > > old meta type name in the dropdown. When I try to reference objects > > by metatype in my code, the new name does work, so it appears that the > > new metatype is ... mostly ... applied. > > > > Is this a bug? Or is the some other location where I also need to > > change this info? You must also change the factory, specifically the 'add list name'. See my previous message: http://zope.nipltd.com/public/lists/zope-archive.nsf/47ba74c812dbc5dd8025687f0024bb5f/6163e128ae1c60db802569b400388292?OpenDocument Ivan ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
