RE: [Zope-dev] ZPatterns: getItem returns None

2001-03-19 Thread Roch'e Compaan


 In my experience, getItem will return None if *anything* goes wrong
 with data retieval or object creation.  Sometimes you get a traceback in
 the STUPID_LOG, and sometimes you don't (and I haven't figured out the
 pattern yet).  Test everything you can independently, and simplify
 everything to the bare minimum until you get it to work, and then
 add back the other variables, etc.

In all simplicity I still can't get it to work but here's some more info
from the console:

Traceback (innermost last):
  File
C:\PROGRA~1\ZOPE230\lib\python\Products\ZPatterns\AttributeProviders.py,
line 335, in _AttributeFor
(Object: GAPMixin)
  File C:\PROGRA~1\ZOPE230\lib\python\Products\ZPatterns\Expressions.py,
line 13
6, in eval
KeyError: AllotmentArea_ID

Roch


___
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] INSTANCE_HOME vs. SOFTWARE_HOME

2001-03-19 Thread Martijn Pieters

On Sun, Mar 18, 2001 at 10:18:52PM +0100, Morten W. Petersen wrote:
 Hi guys,
 
 some people have asked me to use INSTANCE_HOME instead of SOFTWARE_HOME,
 which breaks their products on debian distros.
 
 Now, I'm not sure that won't break other systems if I change it; anyone
 care to share?

What are you using the variable for?

If you want to reach the var, import or Extensions directories, use
INSTANCE_HOME, if you want to reach a Products directory, use both
variables.

On Debian systems, Zope is by default installed as a seperate
INSTANCE_HOME and SOFTWARE_HOME system.

-- 
Martijn Pieters
| Software Engineer  mailto:[EMAIL PROTECTED]
| Digital Creations  http://www.digicool.com/
| Creators of Zope   http://www.zope.org/
-

___
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] FTP interface being worked on?

2001-03-19 Thread Shane Hathaway

Chris McDonough wrote:
 That's one use, which is important to you.  Another is to
 use Emacs or Dreamweaver on a representation of, for
 example, DTML methods on a filesystem, which is important to
 other folks.

I think there is really only one issue nobody has been able to sort out:
do we want the objects to be actually stored on the filesystem or do we
want to be able to mirror a ZODB?  Or do we want both?

 Nobody wants to edit XML, AFAICT.

Careful, that's a religious issue in some circles. :-)  I know of many
people who prefer that data be stored in XML just because humans can
read and change it if the need arises.  (This from a guy who has
actually edited ZODB XML export files. :-) )

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] FTP interface being worked on?

2001-03-19 Thread Fred Wilson Horch

I hadn't thought of the issues you raise.  Thanks for mentioning them.

"John D. Heintz" wrote in part:
 If we
 standardize "properties" to an XML file, then optionally dump other
 files to expose specific aspects of an instance for serialized editing
 it might not be as big a problem as I was thinking.

I think that is the shared vision.  Some aspects of each object could be
serialized into a format that is easy to edit.  For those aspects we
leave it up to the developer of the object to write a serialization
method -- we don't try to guess what an "easy to use" format would look
like.

Other aspects of objects might be impossible to serialize into a
meaningful format.  For those we have a default like XML pickle --
essentially a black box.

 I guess I would suggest that the serialized form of a Zope instance by
 default would be a single XML file, but that arbitrary sections of that
 XML file could be custom dumped to separate serialized files with
 similiar names.  That way authors would have a pretty easy job of
 overriding sections of the dump process to spit out one or more simple
 files that have little parsing overhead.

Sounds reasonable.

  2) A lesser problem is when trying to edit the serialized "files".
  Because objects are methods and state how you modify an object can
  be guided if not controlled.  When we have serialized the
  objects in a Zope system to files, we have exported only the state
  of the objects in the ZODB.  We then have to live with the ability
  to foul up invariant across many objects by changing some data in
  the serialized format.  A good example would be ZCatalogs. [...]
 
  Yup... it's probably easiest to make ZCatalogs a black box.
 
 Black box doesn't solve this problem, only the first one.  Imagine that
 I move a serialized version of a Zope object that is indexed by an
 instance of ZCatalog (or many for that matter).  When I move it the
 ZCatalogs must be notified to handle the change, but only at import time
 because ZCatalogs are serialized as binary for lots of good reasons.

I see the problem.  I think the example you give can be handled
adequately at import time.

But I can see other examples where allowing edits to the serialized
representation could create problems that would be impossible to resolve
at import.

So it seems like we might want to make some things read only.  That is,
when you serialize the objects in the Zope ODB to a filesystem, some of
those serialized files are read-only "black boxes".  A comment in those
files could let a developer know that to change the information in that
file she needs to do an import, or edit the ODB directly.

 When I import the object
 from the serialized format all I can know is that something changed, but
 without expensive processing (XML diffing is hard in the general case,
 we might be able to limit the structures to managable scope though) we
 can't know that the "foo" ZCatalog should be updated instead of the
 "bar" ZCatalog.

Seems like we will need to consider the import code very carefully.

I don't know enough about how ZCatalog works to discuss the options
intelligently.  But in other indexing systems I have worked with, there
have been solutions for reindexing when making updates to the corpus.

  a) XML is structured enough that it can reliably hold the
  data from the
  ZODB.  The current XML dump is not useful for this - it
  would need to
  create individual files and folders to represent
  containment.
 
 
  This is pretty easy right now.  Ten lines of recursive code
  can walk the whole tree if necessary and export only leaf
  objects.

Great.  Maybe I am closer than I realize to the CVS management
solution.  I need to look more closely at ZCVSmixin to see what it
does.  But for our immediate need (which is to allow a distributed team
of developers to share code and track changes via a central CVS
repository), maybe it makes the most sense just to segment the existing
XML export into directories and files and enhance the existing import to
allow overwriting objects.

  b) A hybrid XML and custom dump solution.  An Image for
  example could dump out as a binary image file with meta-data in a
  similiarly name XML file.
 
  Yes, each object should make its own policy regarding its
  body.  Its metadata format should be standardized, however.

I like this idea.

After I have the XML export/import working in a way that fits better
with CVS (even if the sreialized representation is essentially a black
box), then I can tackle how each object represents its body in a
"morally plain text" serialized format.

In other words, first get the default XML representation and
export/import working for all objects.  Then start with the easiest type
of objects to serialize (such as DTML Methods) and create an easy to use
serialization representation.  Then work on the import for that
serialized format.

I think this approach would be different than FSDump and ZCVSMixin,
right?  As far as I understand it, 

Re: [Zope-dev] FTP interface being worked on?

2001-03-19 Thread Chris McDonough

 I think there is really only one issue nobody has been able to sort out:
 do we want the objects to be actually stored on the filesystem or do we
 want to be able to mirror a ZODB?  Or do we want both?

My conception of it is that objects won't be served from the filesystem, but
just put in a editable serialized format for version control and tool
purposes.

  Nobody wants to edit XML, AFAICT.

 Careful, that's a religious issue in some circles. :-)  I know of many
 people who prefer that data be stored in XML just because humans can
 read and change it if the need arises.  (This from a guy who has
 actually edited ZODB XML export files. :-) )

Eek.  ;-)



___
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] FTP interface being worked on?

2001-03-19 Thread John D. Heintz

Fred Wilson Horch wrote:

 I hadn't thought of the issues you raise.  Thanks for mentioning them.

These are issues that may very well affect everyone and I'm happy to 
share my thoughts.

 
 
 I guess I would suggest that the serialized form of a Zope instance by
 default would be a single XML file, but that arbitrary sections of that
 XML file could be custom dumped to separate serialized files with
 similiar names.  That way authors would have a pretty easy job of
 overriding sections of the dump process to spit out one or more simple
 files that have little parsing overhead.
 
 
 Sounds reasonable.
 
 
 2) A lesser problem is when trying to edit the serialized "files".
 Because objects are methods and state how you modify an object can
 be guided if not controlled.  When we have serialized the
 objects in a Zope system to files, we have exported only the state
 of the objects in the ZODB.  We then have to live with the ability
 to foul up invariant across many objects by changing some data in
 the serialized format.  A good example would be ZCatalogs. [...]
 
 Yup... it's probably easiest to make ZCatalogs a black box.
 
 Black box doesn't solve this problem, only the first one.  Imagine that
 I move a serialized version of a Zope object that is indexed by an
 instance of ZCatalog (or many for that matter).  When I move it the
 ZCatalogs must be notified to handle the change, but only at import time
 because ZCatalogs are serialized as binary for lots of good reasons.
 
 
 I see the problem.  I think the example you give can be handled
 adequately at import time.
 
 But I can see other examples where allowing edits to the serialized
 representation could create problems that would be impossible to resolve
 at import.
 
 So it seems like we might want to make some things read only.  That is,
 when you serialize the objects in the Zope ODB to a filesystem, some of
 those serialized files are read-only "black boxes".  A comment in those
 files could let a developer know that to change the information in that
 file she needs to do an import, or edit the ODB directly.

I'm not sure that in the most general case this would solve the problem 
either.  :-(  How do we know when the value (or rather the change in 
value) of a property for some Zope object should trigger some method? 
It depends not only on the object itself, but possibly on many other 
objects.  This is the general problem of separating an objects state 
from its methods.  This is also equivalent to RDBMS triggers and 
referential integrity.

A pretty good example of this would be a Zope Product that provided 
Lamps and Switches.  Several lamps instances could be tied to a single 
switch instance.  When the switch is on, the lamps need to be also.  If 
I dump this to CVS then I can change the lamps and switches data 
separately.  Should all the property values for a lamp be read-only? 
Even the description property?

I understand that the kinds of objects you are working on this for don't 
have many of these problems, and that a very useful system could be 
built given the 80/20 rule.  I'm bringing this up to make sure we know 
what the other 20 means.

 
 
 When I import the object
 from the serialized format all I can know is that something changed, but
 without expensive processing (XML diffing is hard in the general case,
 we might be able to limit the structures to managable scope though) we
 can't know that the "foo" ZCatalog should be updated instead of the
 "bar" ZCatalog.
 
 
 Seems like we will need to consider the import code very carefully.
 
 I don't know enough about how ZCatalog works to discuss the options
 intelligently.  But in other indexing systems I have worked with, there
 have been solutions for reindexing when making updates to the corpus.

As I understand it, the issue with ZCatalog is a good example because of 
the separation of concerns.  A Catalog with indexes that contain Brains 
to get to the actual objects, a Controller that calls reindex/unindex, 
and the objects themselves that don't know they are cataloged.  When I'm 
editing the property "x" of some object "Y" it can be very hard to know 
that it is indexed in some Catalog.  Because it is hard to know I might 
have a difficult time deciding what should be read-only or when doing 
the import of "Y" that I need to call update on some other controller 
object to ensure that the indexes get updated.

 
 
 a) XML is structured enough that it can reliably hold the
 data from the
 ZODB.  The current XML dump is not useful for this - it
 would need to
 create individual files and folders to represent
 containment.
 
 
 This is pretty easy right now.  Ten lines of recursive code
 can walk the whole tree if necessary and export only leaf
 objects.
 
 
 Great.  Maybe I am closer than I realize to the CVS management
 solution.  I need to look more closely at ZCVSmixin to see what it
 does.  But for our immediate need (which is to allow a distributed team
 of developers 

Re: [Zope-dev] FTP interface being worked on?

2001-03-19 Thread John D. Heintz

Chris McDonough wrote:

 I think there is really only one issue nobody has been able to sort out:
 do we want the objects to be actually stored on the filesystem or do we
 want to be able to mirror a ZODB?  Or do we want both?
 
 
 My conception of it is that objects won't be served from the filesystem, but
 just put in a editable serialized format for version control and tool
 purposes.

How useful/difficult would it be to put the SMB protocol on top of a ZEO 
server?  As serialized formats are build, would this be useful to anyone?

Another use for this that I think would be great for is schema 
migration.  Right now with ZODB we can have custom __setstate__() 
methods that do schema migration, but being able to perform text 
processing changes with common tools would be great.

Just thinking out loud...

 
 
 Nobody wants to edit XML, AFAICT.
 
 Careful, that's a religious issue in some circles. :-)  I know of many
 people who prefer that data be stored in XML just because humans can
 read and change it if the need arises.  (This from a guy who has
 actually edited ZODB XML export files. :-) 

 
 
 Eek.  ;-)
 
 
 
 ___
 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 )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
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: getItem returns None

2001-03-19 Thread Roch'e Compaan

 On Mon, 19 Mar 2001, Roch'e Compaan wrote:
  In all simplicity I still can't get it to work but here's some more info
  from the console:
 
  Traceback (innermost last):
File
  C:\PROGRA~1\ZOPE230\lib\python\Products\ZPatterns\AttributeProviders.py,
  line 335, in _AttributeFor
  (Object: GAPMixin)
File C:\PROGRA~1\ZOPE230\lib\python\Products\ZPatterns\Expressions.py,
  line 13
  6, in eval
  KeyError: AllotmentArea_ID

 If I knew more about the internals of ZPatterns I bet this would tell me
 exactly what's wrong, but I don't, so it doesn't.  Have you looked at
 the information screen that tells you which attributes are handled by
 which providers to make sure it is your skinscript that is providing the
 attribute?  To my limited knowledge it looks like maybe the wrong
 attribute

A single line of SkinScript acts as the "Getter" for AllotmentArea_ID:
WITH QUERY sqlGetAllotmentArea(AllotmentArea_ID=self.id) COMPUTE
AllotmentArea_ID, AreaName, AreaCode

There are no persistent attribute or sheet providers - I deleted all of them
and the proxy role for the SkinScript is set to manager.  I fired up the
python debugger as well and it seems if and "instance" is retrieved but the
attribute is not computed as specified by the SkinScript.

 provider is getting into the act.  Hopefully someone with more knowledge
 than me will chime in wry grin.

We'll thanks for your pointers anyway.

Roch



___
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] FTP interface being worked on?

2001-03-19 Thread Chris McDonough

 How useful/difficult would it be to put the SMB protocol on top of a ZEO
 server?  As serialized formats are build, would this be useful to anyone?

I'm not sure how hard it would be, although currently ZEO servers need not
know about anything but strings (they don't necessarily need the code for
the objects they serve lying around anywhere)... It would be pretty neat to
build some sort of SMB access into a Zope client, although I imagine it
would be very difficult.

I think that I may have lost sight of the fact that the representations
we've been throwing around aren't tied to filesystem reps, really.  They're
generic filesystem-like reps that should probably be used for FTP, WebDAV,
SMB, etc.  They're a great case for an "adapter"  ;-)




___
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] Starting a new process

2001-03-19 Thread Chris McDonough

I wonder if you can kick off another thread?

- Original Message -
From: "Christian Ellguth" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 19, 2001 1:52 PM
Subject: [Zope-dev] Starting a new process


 Hi,

 I have a lengthy operation in an external method.
 I takes up to 2 minutes.
 How do I prevent the browser from timing out?
 At the moment I am creating a new process by calling "os.fork()"
 and have that operation done in that new process.
 At the end I call "sys.exit(0)". This worked fine with Zope 2.2.4,
 but Zope 2.3 gives me an error message when calling sys.exit .
 But sys.exit is the only way to end the child-process.

 Can anybody tell me what's the best way to handle a lengthy operation in
an
 external method?

 Thanks

 Christian

 
 Christian Ellguth
 Rebenring 64
 App. 04-05-22
 38106 Braunschweig
 Tel.: 05 31 - 3 88 40 78
 Mobil: 01 77 - 2 39 20 52
 e-mail: [EMAIL PROTECTED]
 ICQ#: 41965033


 ___
 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] Starting a new process

2001-03-19 Thread Christian Ellguth

Hi,

I have a lengthy operation in an external method.
I takes up to 2 minutes.
How do I prevent the browser from timing out?
At the moment I am creating a new process by calling "os.fork()"
and have that operation done in that new process.
At the end I call "sys.exit(0)". This worked fine with Zope 2.2.4,
but Zope 2.3 gives me an error message when calling sys.exit .
But sys.exit is the only way to end the child-process.

Can anybody tell me what's the best way to handle a lengthy operation in an
external method?

Thanks

Christian


Christian Ellguth
Rebenring 64
App. 04-05-22
38106 Braunschweig
Tel.: 05 31 - 3 88 40 78
Mobil: 01 77 - 2 39 20 52
e-mail: [EMAIL PROTECTED]
ICQ#: 41965033


___
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: getItem returns None

2001-03-19 Thread Steve Spicklemire


Hi Roche,

  In all simplicity I still can't get it to work but here's some more info
  from the console:
 
  Traceback (innermost last):
File
  C:\PROGRA~1\ZOPE230\lib\python\Products\ZPatterns\AttributeProviders.py,
  line 335, in _AttributeFor
  (Object: GAPMixin)
File C:\PROGRA~1\ZOPE230\lib\python\Products\ZPatterns\Expressions.py,
  line 13
  6, in eval
  KeyError: AllotmentArea_ID


Seems like the first element of the list of result objects returned by 
sqlGetAllotmentArea doesn't define anything called 'AllotmentArea_ID'.
Could it be a case problem? What datbase/db_adaptor are you using?

You might try changing the skin-script to something like:

WITH (myDebuggingMethod(test_id = self.id) or [NOT_FOUND])[0] COMPUTE 
AllotmentArea_ID, AreaName, AreaCode

then have myDebuggingMethod call an external method to 'print' out things like
the id being used, and the contents of the results being passed back to the
attribute provider. This same method could also return a 'static' dictionary
in a list that has AllotmentArea_ID, AreaName, AreaCode defined as keys, so 
that you know they are there. There was also an exchange on the list between 
Joachim Schmitz and me back in October about some debugging strageties.
You might try to dig those up... 

-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] Status of aq_chain (was: RE: getPhysicalPath?)

2001-03-19 Thread Brian Lloyd

 snip, regarding aq_chain
 
So nobody (including the various Products I have installed) uses this
 incredibly useful attribute. I have numerous places in my source where I
 loop through aq_parent attributes.

A good question is whether aq_chain really should be a 
public interface. It was added (I think) as a debugging 
aid rather than necessarily to be used by application 
code. This is probably one for Jim to answer (I've CC'ed
him on this). If Jim thinks it should be part of the 
public interface, then someone should add a documentation 
bug report on this so that Amos and Michel can see that 
it is included in the right places.


It'd be nice to have even a mention in the acquisition documentation.
 Poking around the Acquisition C source tells me that there's another
 attribute, aq_inner, that isn't documented either.

I think aq_inner is a public interface - this should also 
be a doc bug report.

Before anyone asks, note that 'aq_uncle' is _not_ part of the 
public interface, and is only an exercise in Jim having fun :^)


Brian Lloyd[EMAIL PROTECTED]
Software Engineer  540.371.6909  
Digital Creations  http://www.digicool.com 




___
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 )