Re: [Zope-dev] Data.fs
Andre Schubert writes: > I'am using Zope 2.1.6 and my Data.fs is going corrupted > My Questions are: is there a way to delete the last transaction from > Data.fs, There is a product "tranalyze" (or "tranalyzer", "tranalyse", "tranalyser") that allows you to analyse and fix your Data.fs. Zope 2.2 contains an "ZODB.fsrecover" which is able to fix a corrupted "Data.fs". > and can i backup the Data.fs when Zope is running. Yes. Just copy it. Dieter ___ 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] patch for &dtml-foo:bar:baz;
This may, or may not, break the alternate syntax patch/download @ http://www.zope.org/Members/Coventry/dtml_shortcut I'll investigate and find out, and release a new dtml_shortcut if needbe. (I specifically used a colon since it is valid xml) What about using a colon as the separator, but explicitly give the tag the name dtml-root? having a whole tag of type ':' seems weird (in addition to possibly breaking current patches and such ;) if we didn't want the root to be the default we could use something like with something like _root or __root being set aside as a special name for starting at the root (otherwise it would start in the current directory)...? >>> This patch changes lib/python/DocumentTemplate/DT_HTML.py so that you can use paths for traversal in DTML entity syntax. The delimiter is ':', as it is valid as part of an XML entity, but not valid as part of a Zope object id. You can use &dtml-:foo:bar; to ensure that traversal occurs from the root object. This patch is against Zope 2.2.1b1. It relies on the restrictedTraverse() api. A 2.1.x version would be possible, but would be rather messy. <<< ___ 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] DCOracle w/ 8.0.5 and HP-UX 11
Has anyone gotten this to work. I can get everything to compile but get a bus error when running DCOracle_test.py when importing oci_. I have python compiled with threads and used the -D_POSIX_C_SOURCE=199506L (-D_REENTRANT) flag. Any help would be greatly appreciated, Ron Wood ___ 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] ZPatterns and "Strategies & Patterns etc...."
Steve Spicklemire wrote: > > Hi Folks, > >Well.. I never heard any comments about my last question.. so I > thought I'd try to frame it differently. I just read Coad's book on > Object Models etc.. and I think I pretty well 'grok' it.. at least > enough to be mildly dangerous. ;-) I'm implementing a project with > ZPatterns and I would like to keep a balance between flexibility and > sanity (and of course performance). I've been using 'raw Specialists' > to keep the number of new classes down to a bearable number, but I'm > beginnnig to thing that Zope would behave itself better if I were to > create Product level sub-classes of Specialist instead. I guess I'd > just like to 'hear' what folks think about these different strategies: > > at one end of the spectrum: > > 1) Use ZClasses and 'out of the box' specialists for 90% of the application. >Make ZClass and only where python is *required*, use external methods. I'm using this approach. I'm happy with it. In one current project, I've got nine specialists, twelve ZClasses. I'm using DTML methods and External methods in the specialists. > 10) Use full Python products, possibly subclassed from ZPatterns classes >(DataSkin, Specialist etc) and never use ZClasses at all... I'm using this approach. I'm happy with it. In another current project, I'm building a python product that consists of a single Specialist, plus some python classes that can act as ZClass base classes. This latter project involves more text processing and python stuff. The former project involves workflow and flexible presentation. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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: /, XML, DTML syntaxgeddon
Hi Folks, As for "re-doing" DTML, there's a cogent point made in Extreme Programming circles that goes something like this: "Names matter. For every time someone writes (types?) the name of an object, it will be read 10 times. Pick Good Names." Much of the DTML confusion arises from "names" that look like they were chosen to save typing effort. That may be OK for a project that will never be used by more than a small handful of folks who can answer questions for each other, but Open Source Zope is going on it's second birthday now. Too many newbies keep stumbling over things like "_", which should have been named something meaningful quite some time ago. But that's just one example. Instead of x vs. "x", how about render(x), or x.render(), and execute(x), or x.execute(). Maybe expr="x" and name="y" are clear to someone, but what matters to me is what process is going to be carried out on x and y, and I can't tell that from reading DTML. I do understand that one of the points of OO is that I shouldn't have to know the details of the actual process that happens when I hand one object to another. Ironically, as things are, I have to "know" anyhow, in order to get things working. But the worst part is, even after working through many examples of complex DTML, this stuff is still not "obvious". The greatest mystery to me is how something this obscure could have possibly been written in Python, which is about as obvious as code gets. Still Zopin', Jerry S. ___ 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] ZPatterns and "Strategies & Patterns etc...."
Hi Folks, Well.. I never heard any comments about my last question.. so I thought I'd try to frame it differently. I just read Coad's book on Object Models etc.. and I think I pretty well 'grok' it.. at least enough to be mildly dangerous. ;-) I'm implementing a project with ZPatterns and I would like to keep a balance between flexibility and sanity (and of course performance). I've been using 'raw Specialists' to keep the number of new classes down to a bearable number, but I'm beginnnig to thing that Zope would behave itself better if I were to create Product level sub-classes of Specialist instead. I guess I'd just like to 'hear' what folks think about these different strategies: at one end of the spectrum: 1) Use ZClasses and 'out of the box' specialists for 90% of the application. Make ZClass and only where python is *required*, use external methods. at the other end of the spectrum: 10) Use full Python products, possibly subclassed from ZPatterns classes (DataSkin, Specialist etc) and never use ZClasses at all... and there is the middle ground: 5) Use python products for low level logic. Create overriding methods that can be 'dropped in' at the admin interface level, or in a subclass, later to change the behavior (e.g., retrieveItem ). Make ZClass sub- classes so that userinterface can be easily modified later, and so that persistent propertysheets are easy to add... There are problems with each end of this spectrum... 1) There are still limitations on what you can easily do outside of python. PythonMethods are great but they have strict security limitations that make them cumbersome in some cases. When you want to call a method of an object, that is really a 'DTML/Python Method' you need to pass along context so you end up with a lot of: This seems like a lot of monkey-business just to call a method. Also.. nested withs can generate problems with namespace pollution.. and unfortunately performance. 5) Same problems as above when invoking methods that are implemented as DTML/Python Methods.. otherwise.. not too bad.. this is where I'm living at the moment. All my DataSkin classes are structured as: DataSkin --> myBaseClass -> zSubClassableWrapper -> ZClass My Specialists are just plain old Secialists... (here's the problem.. should they be Python products so that they can have plain Python methods? 10) Everything is defined in Products... harder to integrate into other apps since it's hard to override/change methods without modifying source code on the file system. I can't believe everyone is doing it this way.. but then I con't believe that folks are pushing and popping namespaces all over the place like I seem to in my app Anyway.. thoughts are appreciated. ;-) thanks, -steve ___ 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: /, XML, DTML syntaxgeddon
From: Chris Withers <[EMAIL PROTECTED]> > I suggested the / thing to Steve who pointed out that > &dtml-/folder/object; is bad XML/SGML and so 'Not a Good thing (tm)' Yes, well, making DTML compatible with XML is explicitly *not* a current goal, although having ':' as an alternative separator should make folks who have to deal with it happy. In all other naming areas, especially indirect reference (ie. expr="_['/folder/object']") I much prefer slashes. > What's this DTML syntaxgeddon then? ;-) > This sounds like something I'd really be interested in as you can see > from my ZTL proposal on dev.zope.org. There are so many ideas for revising DTML that the whole thing ought to be done as a single large change (the syntaxgeddon) rather than dribbling out new features and spellings over time. That can easily make people feel that they can't keep up with "all these crazy changes". > However, I'm pretty confident that when say DTML is a mess right now, > I'm not far wrong. How can I get involved in the process to try and > rectify this? Just keep giving feedback on those proposals. Cheers, Evan @ digicool & 4-am ___ 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] why is manage_addZSQLMethod unavailable ?
>Why does this work > >Title','method text')"> > > >While this does not: > >'DB','','select * from data')"> > >Error Type: AttributeError > Error Value: manage_addZSQLMethod > >I studies the Znolk product and found that it uses _setObject directly >instead of >manage_addZSQLMethod . > In general there is an inconsistency in adding objects: sometimes you can use the manage_addYourProduct interface, and sometimes only going through the addProduct invocation (don't have the whole thing handy here) will do the trick. This can get very confusing. Wouldn't know if that's the matter here, though. I think this should be standardized in the interfaces. >but it IMHO the visibility of manage_addDTMLMethod and manage_addZSQLMethod >_should_ be the same ? > I agree ___ 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] why is manage_addZSQLMethod unavailable ?
Why does this work While this does not: Error Type: AttributeError Error Value: manage_addZSQLMethod I studies the Znolk product and found that it uses _setObject directly instead of manage_addZSQLMethod . I was able to overcome it by defining an one-line external method: - from Products.ZSQLMethods.SQL import * def manage_addZSQLMethod(self, sqlId, sqlTitle, connection_id, args, command): self._setObject(sqlId, SQL(sqlId, sqlTitle, connection_id, args, command)) - but it IMHO the visibility of manage_addDTMLMethod and manage_addZSQLMethod _should_ be the same ? - Hannu ___ 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] /, XML, DTML syntaxgeddon
Evan Simpson wrote: > There a patch sitting around waiting for DTML syntaxgeddon which allows > slash-separated paths in object names everywhere, not just in entity syntax. > That could easily be extended to also allow colons as separators. Cool :-) I suggested the / thing to Steve who pointed out that &dtml-/folder/object; is bad XML/SGML and so 'Not a Good thing (tm)' What's this DTML syntaxgeddon then? ;-) This sounds like something I'd really be interested in as you can see from my ZTL proposal on dev.zope.org. Sadly, that didn't seems to get very far :( However, I'm pretty confident that when say DTML is a mess right now, I'm not far wrong. How can I get involved in the process to try and rectify this? cheers, Chris PS: Part of the 'DTML problem' is the lack of well defined interfaces for some things, and, more importantly, a decent generalised method interface covering DTML methods, Python Methods, Perl Methods, External Methods, etc.. ___ 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] Caching problems
Bob Pepin wrote: > > On Wed, Aug 16, 2000 at 05:31:29PM +0100, Carlos Neves wrote: > > You directly change a nonpersistence participant object. > > As stated in > > http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html : > [...] > > but mainly... RTFM ;-) > > Well, thanks, but too bad the only FM I've been able to find about Zope are > those .py files in lib/python/... > > I spent a whole day looking for documentation on ZODB internals on zope.org and > zdp.zope.org, without being able to find anything... how about adding that > paper to the search engine on zope.org? Is there more documentation like that > one out there? a couple actually, not located so that you can find them but they exist jim fulton's paper from the ipc8 (python conference) is excellent reading material. http://www.zope.org/Members/jim/Info/IPC8/ZODB3News also the uml models http://www.zope.org/Documentation/Developer/Models/ZODB/ and another excellent paper by andrew kuchling on zodb and ZEO http://starship.python.net/crew/amk/python/writing/zodb-zeo.html there is also a how-to... Cheers Kapil ___ 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 )
