Re: [Zope-dev] Recursive folders from Python

2000-10-31 Thread Phil Harris

Try something like (taken from my own code, so it works for me, caveta
emptor):

def mkcontext(self,context=None):
global default_dd
if not context:
return 'EH!'
c=string.split(context,'/')
newself=self
for a in c:
try:

newself.manage_addFolder(a,createPublic=0,createUserF=0,REQUEST=getattr(self
,'REQUEST',None))
except:
pass
newself=getattr(newself,a) ## this is the relevant line
newself.manage_addLocalRoles(c[-1],['Manager'])
try:
newself.manage_addDTMLMethod('index_html','Start
Page',file=default_dd)
except:
pass

This func takes a slash separated list of folders (actually a NDS context
like 'dacs/media/stf/wmlph' and creates the folder hierarchy.

It's probably overkill for what you want but the relevant line is the
getattr one (as marked).

hth

Phil



- Original Message -
From: "Dieter Maurer" [EMAIL PROTECTED]
To: "Jason Spisak" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, October 30, 2000 6:43 PM
Subject: Re: [Zope-dev] Recursive folders from Python


 Jason Spisak writes:
   Does anyonw know why this code won't create a folder within a folder.
   It's tells me the id is already in use, so that means it's not
   descending into the newly created folder to make another folder.
  
   def create(self):
   for digit in range(0, 10):
   folder= self.manage_addFolder(str(digit), str(digit))
   subfolder = self.folder.manage_addFolder(str(digit),
str(digit))
 Apparently, the above line should add a new folder in (say) '00'.
 What it does, however, is trying to add the new folder in the object named
 'folder' (accessible from 'self'). This may well go wrong.

 Keep in mind, that the local name space of the function 'create'
 (where your variable 'folder' lives) is disjunct from the attribute
 namespace of 'self' (where the attribute 'folder' lives).


 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 )


___
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] Using the monitor_client

2000-10-31 Thread Morten W. Petersen

When using the monitor_client, I do this:

-- Start monitor_client usage

python monitor_client.py localhost 8099
Enter Password:
warning: unhandled connect event
Python 1.5.2 (#1, Mar 11 2000, 13:03:53)  [GCC 2.95.2 19991024 (release)]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Welcome to secure_monitor_channel connected 127.0.0.1:2959 at 88fbf80
 import Zope
 app=Zope.app()
 app.addDTMLMethod
Traceback (innermost last):
  File "/usr/local/Zope/ZServer/medusa/monitor.py", line 94, in found_terminator
result = eval (co, self.local_env)
  File "secure_monitor_channel connected 127.0.0.1:2959 at 88fbf80", line 0, in ?
AttributeError: addDTMLMethod
 app.manage_addDTMLMEthod
Traceback (innermost last):
  File "/usr/local/Zope/ZServer/medusa/monitor.py", line 94, in found_terminator
result = eval (co, self.local_env)
  File "secure_monitor_channel connected 127.0.0.1:2959 at 88fbf80", line 0, in ?
AttributeError: manage_addDTMLMEthod
 app.manage_addDTMLMethod
Python Method object at 82ee058
 app.manage_addDTMLMethod('tester','tester','tester')
''
 app._p_jar.sync()
 get_transaction().commit()
 warning: unhandled close event

closed.
morten@slakka:/usr/local/Zope/ZServer/medusa 

-- End monitor_client usage

However, when I enter the management screen of the Zope instance, no DTMLMethod
called tester is listed..

(I used http://www.zope.org/Documentation/Misc/DEBUGGING.txt as a guide..)

Can anyone see what I'm doing wrong?

Thanks in advance.

-Morten

___
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 + Skinscript

2000-10-31 Thread Steve Spicklemire


OK I think I found the problem(s):

*** Expressions.py  2000/10/18 23:11:55 1.1.1.3
--- Expressions.py  2000/10/31 14:14:09
***
*** 133,139 
  def eval(self,mapping):
  """Return the result of looking up/calling the name from 'mapping'.
  If the object was created with 'call==1', call it before returning it."""
! return md.getitem(self.name,self.call)
  
  
  del Eval, expr_globals, TemplateDict, Base, ComputedAttribute
--- 133,139 
  def eval(self,mapping):
  """Return the result of looking up/calling the name from 'mapping'.
  If the object was created with 'call==1', call it before returning it."""
! return mapping.getitem(self.name,self.call)
  
  
  del Eval, expr_globals, TemplateDict, Base, ComputedAttribute

*** SkinScript/Compiler.py  2000/10/18 23:11:56 1.1.1.4
--- SkinScript/Compiler.py  2000/10/31 14:12:09
***
*** 168,174 
  
  class Compute(AST):
  type = 'COMPUTE'
! def __init__(self,*args,**args):
  self._kids=list(args)+kw.items()
  
  class Trigger(Compute):
--- 168,174 
  
  class Compute(AST):
  type = 'COMPUTE'
! def __init__(self,*args,**kw):
  self._kids=list(args)+kw.items()
  
  class Trigger(Compute):


Try these patches and see if it works... 

-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] Using the monitor_client

2000-10-31 Thread Morten W. Petersen

[Yves-Eric Martin]

| - Zope.app() gives you a *copy* of the *real* application object.
| - app._p_jar.sync() reloads your copy with the real (losing your changes)

Ah, there it is; sync discards the changes made from the monitor, and then
reloads...

An extra thanks for the thorough (not-very-newbie-like) explanation, much
appreciated!  =)

-Morten

___
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] Using the monitor_client

2000-10-31 Thread Shane Hathaway

Yves-Eric Martin wrote:
 I am no Zope monitor expert, but maybe you will find my newbie point

For some definition of newbie... :-)

 of view helpful. Here is my understanding of the magic of this very
 helpful tool:
 
 - Zope.app() gives you a *copy* of the *real* application object.
 - app._p_jar.sync() reloads your copy with the real (losing your changes)
 - get_transaction().commit() writes your copy to the real (applying your
 changes)

I didn't realize sync() was there.  Thanks for the tip!

Shane

___
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 + Skinscript

2000-10-31 Thread Steve Spicklemire


Hi Joachim,

 "Joachim" == Joachim Schmitz [EMAIL PROTECTED] writes:

Joachim Hi Steve,
Joachim that did it, many thanks, how did you debug this ? 

The debugger is your friend. ;-). Seriously I'd be lost without it:

http://www.zope.org/Members/michel/HowTos/TheDebuggerIsYourFriend

Joachim By the way, it only work if specify a DataSkin derived ZClass
Joachim under the Storage tab.

Yes... did you attempt to use a 'pure' DataSkin?

-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 + Skinscript

2000-10-31 Thread Joachim Schmitz

Hi Steve,

On Tue, 31 Oct 2000, Steve Spicklemire wrote:

 
 Joachim By the way, it only work if specify a DataSkin derived ZClass
 Joachim under the Storage tab.
 
 Yes... did you attempt to use a 'pure' DataSkin?
 
after your advise not to use a 'pure' DataSkin, I did all the testing with a
DataSkin derived ZClass, when that was working, I tried the 'pure' DataSkin
and it didn't work.


Mit freundlichen Grüßen

Joachim Schmitz  

  
AixtraWare, Ing. Büro für Internetanwendungen
Hüsgenstr. 33a, D-52457 Aldenhoven  
Telefon: +49-2464-8851, FAX: +49-2464-905163


___
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] Compiling of the DynPersist module (ZPatterns)

2000-10-31 Thread Phillip J. Eby

At 04:44 PM 10/30/00 +0100, Morten W. Petersen wrote:
After compiling the DynPerist module, I try to import it in the Python
interpreter:

"""
morten@slakka:/usr/local/Zope/lib/python/Products/ZPatterns  gcc -o
DynPersist.so -c DynPersist.c -I../../ZODB
-I../../../Components/ExtensionClass -I/usr/include/python1.5
morten@slakka:/usr/local/Zope/lib/python/Products/ZPatterns  python
Python 1.5.2 (#1, Mar 11 2000, 13:03:53)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
 import DynPersist
Traceback (innermost last):
  File "stdin", line 1, in ?
ImportError: ./DynPersist.so: ELF file's phentsize not the expected size

"""

Any ideas what I'm doing wrong (is it maybe the compiler)?


There's a couple things wrong here.  First, you're compiling a .c directly
to an .so, which is wrong.  GCC is obeying your command and making a .o
file with an .so extension, which will not work.  You really should use the
standard python module make process.  Copy Makefile.pre.in from your python
tree into the directory, then run "make -f Makefile.pre.in boot", followed
by "make".  Then you'll end up with a working DynPersist.so.

Second, don't try to load it from python in the ZPatterns directory,
because DynPersist is dependent on the cPersistence and ExtensionClass .so
modules, which Python won't be able to find if you run it in that
directory.  You need to include the directories containing those things on
your PYTHONPATH, if you want to use it.  As a practical matter, however,
DynPersist is pretty useless outside the Zope environment, so I'd say just
build it the correct way and give it a try in Zope.


___
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 + Skinscript

2000-10-31 Thread Phillip J. Eby

At 04:42 PM 10/31/00 +0100, Joachim Schmitz wrote:
Hi Steve,

On Tue, 31 Oct 2000, Steve Spicklemire wrote:

 
 Joachim By the way, it only work if specify a DataSkin derived ZClass
 Joachim under the Storage tab.
 
 Yes... did you attempt to use a 'pure' DataSkin?
 
after your advise not to use a 'pure' DataSkin, I did all the testing with a
DataSkin derived ZClass, when that was working, I tried the 'pure' DataSkin
and it didn't work.


DataSkin is strictly a mix-in class.  Sometimes I forget to remind people
of that, and sometimes I even forget it myself.  :(


___
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 + Skinscript

2000-10-31 Thread Itamar Shtull-Trauring

"Phillip J. Eby" wrote:

 DataSkin is strictly a mix-in class.  Sometimes I forget to remind people
 of that, and sometimes I even forget it myself.  :(

DataskinAddons provides a nice DataSkin-derived class for debugging purposes
- it has a debug() method that prints out __dict__, and lets you getattr
attributes through the web as well. So you can use that for testing
purposes.

http://www.zope.org/Members/stevea/DataSkinAddons

-- 
Itamar S.T.  [EMAIL PROTECTED]
Fingerprint = D365 7BE8 B81E 2B18 6534  025E D0E7 92DB E441 411C

___
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/PlugIns bug fix releases

2000-10-31 Thread Phillip J. Eby

I've released new 0.4.3 beta 2 versions of ZPatterns and PlugIns to fix the
minor bugs reported to date in beta 1.  Specifically, the PlugIns package
now contains a "help" directory, and the problem with "name" shorthand in
SkinScript has been fixed as well.  They can be found in the usual places.

(By the way, if you haven't yet seen the latest zope.org download page,
it's really cool...  go to http://www.zope.org/Products/ and check it out.)


___
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] Questions about implementing object models with ZPatterns

2000-10-31 Thread Itai Tavor

Hi,

How do I implement gen-spec classes using ZPatterns and ZClasses? 
For example, I want to implement Person and Customer. Writing it in 
Python, it would be easy to subclass Person to get Customer, and 
Customer would inherit Person's properties and methods. If I instead 
create a specialist and ZClass for each class, do I use a SkinScript 
to remap Person's properties into Customer? And what about the 
methods - Customer can't inherit Person's methods, so I have to write 
methods in Customer which call the same methods in Person. This seems 
terribly complicated... am I missing something?

Another question: In Coad's examples, if a class has an 'n' order 
relationship to another class - say Order and OrderItems, Order would 
contain a list of OrderItems. Each OrderItem would contain the id of 
the Order it belongs to. It seems to me that it would be easier for 
Order to call OrderItems.getItemsForOrder(self.id), then I don't have 
to maintain a list in Orders, and if I add an OrderItem the Order 
will immediately know about it without me having to call it and tell 
it the OrderItem was added. Is there anything wrong with this 
approach?

TIA,

Itai
-- 
Itai Tavor"Je sautille, donc je suis."
C3Works[EMAIL PROTECTED]  - Kermit the Frog

"If you haven't got your health, you haven't got anything"


___
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] Questions about implementing object models with ZPatterns

2000-10-31 Thread Phillip J. Eby

At 12:35 PM 11/1/00 +1100, Itai Tavor wrote:
Hi,

How do I implement gen-spec classes using ZPatterns and ZClasses? 
For example, I want to implement Person and Customer. Writing it in 
Python, it would be easy to subclass Person to get Customer, and 
Customer would inherit Person's properties and methods. If I instead 
create a specialist and ZClass for each class, do I use a SkinScript 
to remap Person's properties into Customer? And what about the 
methods - Customer can't inherit Person's methods, so I have to write 
methods in Customer which call the same methods in Person. This seems 
terribly complicated... am I missing something?

If you want subclasses, just subclass ZClasses.  As for the remapping,
etc., it depends on what you want to do.  Keep in mind that Specialists are
created per *role* or *interface*, not per class.  You can have a "People"
specialist that has a personRack and a customerRack in it, for example.
Specialists are application- and usage-driven; you don't always end up
creating specialists for every class in your object model.

(By the way, note that if you have a personRack and customerRack in the
same specialist, they can share data plug-ins (such as SkinScript methods)
placed directly in the specialist.  The ranking order of the parent
plug-ins in the child racks is determined by where you place a "Link to
Parent Data Plug-Ins" in the racks' data plug-in lists.)


Another question: In Coad's examples, if a class has an 'n' order 
relationship to another class - say Order and OrderItems, Order would 
contain a list of OrderItems. Each OrderItem would contain the id of 
the Order it belongs to. It seems to me that it would be easier for 
Order to call OrderItems.getItemsForOrder(self.id), then I don't have 
to maintain a list in Orders, and if I add an OrderItem the Order 
will immediately know about it without me having to call it and tell 
it the OrderItem was added. Is there anything wrong with this 
approach?

Nothing at all.  It's the recommended approach, actually.  This is how you
make frameworks work...  by delegating to specialists responsible for a
role in the application.  That is, instead of the Orders system having to
know anything about how order items are actually implemented, it can
delegate that function to an OrderItems specialist that could have such
things as DiscountItems, ReturnItems, and all sorts of other objects that
implement an OrderItem interface.  Similarly, rather than an Order
providing its own interface for entering an order item, the UI code can be
(should be) placed in the OrderItems specialist, and called by the Order
object's add/edit forms.

Encapsulation at its very best.  :)  That's the ZPatterns way; the tools
were specifically created to make it easy to do things the "right" way from
a seperation-of-powers standpoint.


___
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] Questions about implementing object models withZPatterns

2000-10-31 Thread Itai Tavor

Phillip J. Eby wrote:

At 12:35 PM 11/1/00 +1100, Itai Tavor wrote:
Hi,

How do I implement gen-spec classes using ZPatterns and ZClasses?
For example, I want to implement Person and Customer. Writing it in
Python, it would be easy to subclass Person to get Customer, and
Customer would inherit Person's properties and methods. If I instead
create a specialist and ZClass for each class, do I use a SkinScript
to remap Person's properties into Customer? And what about the
methods - Customer can't inherit Person's methods, so I have to write
methods in Customer which call the same methods in Person. This seems
terribly complicated... am I missing something?

If you want subclasses, just subclass ZClasses.  As for the remapping,
etc., it depends on what you want to do.  Keep in mind that Specialists are
created per *role* or *interface*, not per class.  You can have a "People"
specialist that has a personRack and a customerRack in it, for example.
Specialists are application- and usage-driven; you don't always end up
creating specialists for every class in your object model.

Ok... I think I get the "Specialist per role, not per class" part. 
But I still can't make the jump from a class diagram to a 
ZClass/Specialist setup.

I can solve some of it by subclassing ZClasses. So, if I need 
Customers and Resellers, I'll make a Specialist for each, and a 
Customer and Reseller ZClasses, both subclassed from Person which 
stores common properties for a person. This part is ok. But it gets 
more complex than that. Take this example: Every OrderLineItem object 
can have one or more Payment objects associated with it. There are 3 
possible payment types - Check, Charge and BankDeposit, so I make a 
ZClass for each one, all subclassed from a general Payment ZClass. I 
create one Payments Specialist with 3 Racks. Where do I store methods 
that are specific to one payment type? In the Rack? I can't store 
them in the Specialist - it would be a mess, and I can't store them 
in the ZClass, because the ZClass doesn't know about the rest of the 
application. Actually, writing this down makes me realize that it 
could work... would Payments.getItem(some_payment_id).someMethod() 
call someMethod in the Rack if one exists, and the one in the 
Specialist if not? I guess that would make it very easy... 
subclassing moves into the Specialist.

Another problem I'm having is how to store id's for different objects 
in the the same field. In the Payments example above this is not a 
problem, because all payments are supplied by the Payments 
specialist. But what about another example - Customers and Resellers 
are two totally different roles, so they each get a Specialist. the 
Payment object has from_id and to_id fields, and each of those can 
hold the id of a customer or reseller, or some special code to 
indicate the store. I could add from_type and to_type fields, or I 
could prefix the id with a code letter, but neither seem like a good 
solution. Is there a recommended approach for solving this problem?


(By the way, note that if you have a personRack and customerRack in the
same specialist, they can share data plug-ins (such as SkinScript methods)
placed directly in the specialist.  The ranking order of the parent
plug-ins in the child racks is determined by where you place a "Link to
Parent Data Plug-Ins" in the racks' data plug-in lists.)


Another question: In Coad's examples, if a class has an 'n' order
relationship to another class - say Order and OrderItems, Order would
contain a list of OrderItems. Each OrderItem would contain the id of
the Order it belongs to. It seems to me that it would be easier for
Order to call OrderItems.getItemsForOrder(self.id), then I don't have
to maintain a list in Orders, and if I add an OrderItem the Order
will immediately know about it without me having to call it and tell
it the OrderItem was added. Is there anything wrong with this
  approach?

Nothing at all.  It's the recommended approach, actually.  This is how you
make frameworks work...  by delegating to specialists responsible for a
role in the application.  That is, instead of the Orders system having to
know anything about how order items are actually implemented, it can
delegate that function to an OrderItems specialist that could have such
things as DiscountItems, ReturnItems, and all sorts of other objects that
implement an OrderItem interface.  Similarly, rather than an Order
providing its own interface for entering an order item, the UI code can be
(should be) placed in the OrderItems specialist, and called by the Order
object's add/edit forms.

Encapsulation at its very best.  :)  That's the ZPatterns way; the tools
were specifically created to make it easy to do things the "right" way from
a seperation-of-powers standpoint.

Thanks! I feel a little better now :)
-- 
Itai Tavor"Je sautille, donc je suis."
C3Works[EMAIL PROTECTED]  - Kermit the Frog

"If you haven't got your health, you