Re: [Zope-dev] Caching problems

2000-08-18 Thread Kapil Thangavelu

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 )




[Zope-dev] why is manage_addZSQLMethod unavailable ?

2000-08-18 Thread Hannu Krosing

Why does this work

dtml-call "_['testadd'].manage_addDTMLMethod('MethodId', 'Method
Title','method text')"


While this does not:

dtml-call "_['testadd'].manage_addZSQLMethod('ZSQLID', 'ZSQL Title',
'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 .

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 )




Re: [Zope-dev] why is manage_addZSQLMethod unavailable ?

2000-08-18 Thread Rik Hoekstra





Why does this work

dtml-call "_['testadd'].manage_addDTMLMethod('MethodId', 'Method
Title','method text')"


While this does not:

dtml-call "_['testadd'].manage_addZSQLMethod('ZSQLID', 'ZSQL Title',
'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] Re: /, XML, DTML syntaxgeddon

2000-08-18 Thread Evan Simpson

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 )




[Zope-dev] ZPatterns and Strategies Patterns etc....

2000-08-18 Thread Steve Spicklemire


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:

   dtml-with FooManager

  dtml-let theResult="aMethodOfTheFooManager( )"


  /dtml-let

   /dtml-with

   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 )




Re: [Zope-dev] ZPatterns and Strategies Patterns etc....

2000-08-18 Thread Steve Alexander

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] DCOracle w/ 8.0.5 and HP-UX 11

2000-08-18 Thread Ron_Wood



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] patch for dtml-foo:bar:baz;

2000-08-18 Thread Jon Franz

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?
dtml-root foo:bar:childofbar

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
dtml-trans [path]:[path] 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 )




Re: [Zope-dev] Data.fs

2000-08-18 Thread Dieter Maurer

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 )