Re: [Zope-dev] ZPT in Zope Products

2004-04-15 Thread Santi Camps
Wyatt Anderson escribi:

Hello All,

I am trying to use ZPT within a Zope Product I am trying to build.

I want to test the container type I am addding to to determine what

action to take. The following though

from Products.PageTemplates.PageTemplateFile import PageTemplateFile

def manage_addMyContainerForm(self, REQUEST):

pt = None

if self.meta_type in [ContainerType1, ContainerType2]:

pt = PageTemplateFile(zpt/addMyContainerForm, globals())

else:

pt = PageTemplateFile(zpt/containerError, globals())

return pt.pt_render()

This produces the following traceback in Zope:

Traceback (innermost last):

 Module ZPublisher.Publish, line 100, in publish

 Module ZPublisher.mapply, line 88, in mapply

 Module ZPublisher.Publish, line 40, in call_object

 Module Products.MyContainer.MyContainer, line 17, in manage_addMyContainerForm

 Module Products.PageTemplates.PageTemplate, line 90, in pt_render

  - PageTemplateFile at containerError

 Module Products.PageTemplates.PageTemplateFile, line 73, in pt_getContext

TypeError: 'str' object is not callable

Ive checked out the code in PageTemplate.py and PageTemplateFile.py 
and cant

figure out what is going on. The line in question is

root = self.getPhysicalRoot()

Is it possibly some security thing? My class is 
setDefaultAccess(allow) for now.

Ive also tried simply

return pt

with no traceback but without the desired results as the object is 
returned.

Thanks in advance,

Wyatt

Try return pt()

Santi Camps

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZODB for Java?

2004-04-15 Thread Romain Slootmaekers
Ian Beatty wrote:
Greetings.

Does anyone know of a good (stable, reliable, fast enough for production 
use in a web app) ZODB-equivalent for persisting Java objects?
www.jdocentral.com


Thanks,

..Ian

-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
Dr. Ian Beatty   [EMAIL PROTECTED]
Physics Education Researchvoice: 413.545.9483
Department of Physics   fax: 413.545.4884
Univ. of Massachusetts  AIM: (available upon request)
Amherst, MA 01003-9337 USA   http://umperg.physics.umass.edu/
-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Philipp von Weitershausen
Jim,

let's make this telegraph style :)

OK, here's another.

What about renaming the Zope 3 zope package to z.
+1

- It fits with the expansion of Zope:
  Z Object Publishing Environment.
- It's short :)

- *At this time* (but after the move to svn), it's not too hard to make
  a change like this for Zope 3. Backward compatibility is not a big
  issue. This will change when X3.0 is released, which is why I'm
  bothering to deal with this now.
+1

Other reasons I like z:

- Less noise in imports
+1

- Echos the circle z
+0  (that's a marketing issue ;))

- The packages in z can be used for more than just Zope
+2

- Emphasizes the more minimalist nature of Zope 3 relative
  to Zope 2
+2

Philipp

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope and zope

2004-04-15 Thread Stefan H. Holek
+0, not a problem. -1 for renaming 'Zope'.

I endorse the 'src/zope' idea.

Stefan

On Mittwoch, Apr 14, 2004, at 15:00 Europe/Vienna, Jim Fulton wrote:

Perhaps we can get more input on whether there's a problem.

A response with a positive sign (e.g. +1, +0, +2, ...) indicates
agreement that this is a probelm. :)
--
The time has come to start talking about whether the emperor is as well
dressed as we are supposed to think he is.   /Pete McBreen/
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Sidnei da Silva
On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote:
| - The packages in z can be used for more than just Zope
| 
| +2

So, here's an idea:

 - Move component-architecture packages out of 'zope' into 'ca', and
   then we don't have the 'zope' vs 'Zope' issue anymore.

I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*.

So, what about this:

zope.component
zope.interfaces (?)
zope.configuration
zope.testing
zope.schema (soon-to-be-dead?)

- All move to 'ca.*'

zope.app.*

- Move down to 'zope'.

This is pretty rough. Probably there are more stuff that should move
to 'ca', and some stuff which should be grouped into packages, so that
'zope' doesn't get excessively broad.

-- 
Sidnei da Silva [EMAIL PROTECTED]
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

Breadth-first search is the bulldozer of science.
-- Randy Goebel

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote:
| - The packages in z can be used for more than just Zope
| 
| +2

So, here's an idea:

 - Move component-architecture packages out of 'zope' into 'ca', and
   then we don't have the 'zope' vs 'Zope' issue anymore.
I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*.
Great

So, what about this:

zope.component
zope.interfaces (?)
zope.configuration
zope.testing
zope.schema (soon-to-be-dead?)
- All move to 'ca.*'
Most of this has nothing to do with the component architecture.

ca has nothing to do with zope.

zope.app.*

- Move down to 'zope'.
This doesn't solve name-conflict the problem. Or maybe I don't understand what you
are proposing.
This is pretty rough. Probably there are more stuff that should move
to 'ca', and some stuff which should be grouped into packages, so that
'zope' doesn't get excessively broad.
I think the depth vs breadth balence we have now is about right.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Sidnei da Silva
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote:
| So, what about this:
| 
| zope.component
| zope.interfaces (?)
| zope.configuration
| zope.testing
| zope.schema (soon-to-be-dead?)
| 
| - All move to 'ca.*'
| 
| Most of this has nothing to do with the component architecture.
| 
| ca has nothing to do with zope.

So that's the intention. If it has nothing to do with zope, why it
should be prefixed with 'zope'? 

I may have been unlucky on trying to enumerate the packages. I was
trying to figure out what kind of stuff would be useful in the context
of zope2. Maybe you can enumerate what packages are part of the
component architecture, and what packages would be used in zope2? I
have a feeling that most stuff in zope.app would not be used in zope2,
but I'm mostly surely wrong.

| zope.app.*
| 
| - Move down to 'zope'.
| 
| This doesn't solve name-conflict the problem. Or maybe I don't understand 
| what you
| are proposing.

See above.

-- 
Sidnei da Silva [EMAIL PROTECTED]
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

The most important early product on the way to developing a good product
is an imperfect version.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote:
| So, what about this:
| 
| zope.component
| zope.interfaces (?)
| zope.configuration
| zope.testing
| zope.schema (soon-to-be-dead?)
| 
| - All move to 'ca.*'
| 
| Most of this has nothing to do with the component architecture.
| 
| ca has nothing to do with zope.

So that's the intention. If it has nothing to do with zope, why it
should be prefixed with 'zope'? 
From the zope package README.txt:

  Zope Project Packages

  The zope package is a pure namespace package holding packages developed as
  part of the Zope 3 project.
  Generally, the immediate subpackages of the zope package should be
  useful and usable outside of the Zope application server.  Subpackages
  of the zope package should have minimal interdependencies, although
  most depend on zope.interfaces.
  The one subpackage that's not usable outside the application server is
  the app subpackage, zope.app, which *is* the application
  server. Sub-packages of zope.app are not usable outside of the application
  server. If there's something in zope.app you want to use elsewhere, let us
  know and we can talk about abstracting some of it up out of zope.app.



I may have been unlucky on trying to enumerate the packages. I was
trying to figure out what kind of stuff would be useful in the context
of zope2.
Potentially, all of them.

 Maybe you can enumerate what packages are part of the
component architecture,
zope.component

and what packages would be used in zope2?
All of them, eventually probably including zope.app.

I have a feeling that most stuff in zope.app would not be used in zope2,
but I'm mostly surely wrong.
I think you are probably wrong.

But we don't know for sure yet.

| zope.app.*
| 
| - Move down to 'zope'.
| 
| This doesn't solve name-conflict the problem. Or maybe I don't understand 
| what you
| are proposing.

See above.
I still don't see how having a different package named zope addresses the
name conflict with Zope.
Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Lennart Regebro
From: Sidnei da Silva [EMAIL PROTECTED]
  - Move component-architecture packages out of 'zope' into 'ca', and
then we don't have the 'zope' vs 'Zope' issue anymore.

'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of
course that means that suddenly the component architecture is called z, but
that's OK, isn't it?



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Barry Warsaw
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:

  From the zope package README.txt:
 
Zope Project Packages
 
The zope package is a pure namespace package holding packages developed as
part of the Zope 3 project.
 
Generally, the immediate subpackages of the zope package should be
useful and usable outside of the Zope application server.  Subpackages
of the zope package should have minimal interdependencies, although
most depend on zope.interfaces.

Speaking as someone who's tried to use zope subpackages outside of z3,
there are practical problems with this.  About 8 months ago, I tried to
pull ZPT, et al out to use as a standalone version.  I ended up having
to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and
zope.i18n.  All make sense (especially since I wanted internationalized
ZPT), but tracking all the dependencies were difficult.  I tried to
update all that again a few weeks ago and found that I also now needed
zope.i18nmessageid and zope.schema.

It looks like Fred's packaging work will help with the very tricky task
of figuring out the dependencies and creating distutils packages for the
desired stuff.  I've also heard that zope.schema is going away and that
the dependency on both zope.i18n and zope.i18nmessageid might not be
necessary.

But I'm still concerned that there will be creeping dependencies among
more things inside the zope package, making it harder to use some of
those technologies independently.  E.g. there are several standalone ZPT
implementations in the wild, but I happen to think z3's is the best and
would like to see it adopted more widely in the Python world.

Also, for a long time I've wanted to see z3's interfaces package be used
outside Zope3, perhaps even being adopted as a standard library package
eventually.  I wonder if living inside the zope container package helps
or hurts those prospects.

I understand the desire to carve out a package namespace that z3 can
reliably use without risk of collision with other packages.  I still
think that's less of a practical concern in the Python world so I'd opt
for an approach that gets the non-Zope specific technologies into the
most hands of Python programmers.

-Barry



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Lennart Regebro wrote:
From: Sidnei da Silva [EMAIL PROTECTED]

- Move component-architecture packages out of 'zope' into 'ca', and
  then we don't have the 'zope' vs 'Zope' issue anymore.


'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of
course that means that suddenly the component architecture is called z
No, the component architecture is z.component.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Barry Warsaw wrote:
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:


From the zope package README.txt:

  Zope Project Packages

  The zope package is a pure namespace package holding packages developed as
  part of the Zope 3 project.
  Generally, the immediate subpackages of the zope package should be
  useful and usable outside of the Zope application server.  Subpackages
  of the zope package should have minimal interdependencies, although
  most depend on zope.interfaces.


Speaking as someone who's tried to use zope subpackages outside of z3,
there are practical problems with this.  About 8 months ago, I tried to
pull ZPT, et al out to use as a standalone version.  I ended up having
to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and
zope.i18n.  All make sense (especially since I wanted internationalized
ZPT), but tracking all the dependencies were difficult.  I tried to
update all that again a few weeks ago and found that I also now needed
zope.i18nmessageid and zope.schema.
It looks like Fred's packaging work will help with the very tricky task
of figuring out the dependencies and creating distutils packages for the
desired stuff. 
Eactly. Freds work is going to adress this problem.
(I'll restrain myself from going into a tirade about how important this
is for Python. :)
I've also heard that zope.schema is going away
I thin it will eventually be merged into zope.interface.

 and that
the dependency on both zope.i18n and zope.i18nmessageid might not be
necessary.
Right, maybe

But I'm still concerned that there will be creeping dependencies among
more things inside the zope package, making it harder to use some of
those technologies independently.  E.g. there are several standalone ZPT
implementations in the wild, but I happen to think z3's is the best and
would like to see it adopted more widely in the Python world.
We're aware of this problem. That's why we've decoded to make the dependency
data explicit (manually created) rather than implicit (automatically created).
Each separately distributed package will have a DEPENDENCIES.cfg that is
created by hand and that *constrains* dependencies on other packages. It
makes explicit the intended dependencies. Dependencies not listed here
are bugs.  Adding depenencies to this file should be considered a big deal.
Also, for a long time I've wanted to see z3's interfaces package be used
outside Zope3, perhaps even being adopted as a standard library package
eventually.  I wonder if living inside the zope container package helps
or hurts those prospects.
Probably neither.  I doubt that there will ever be a standard Python
interface system.  I'm not going to hold my breath.  Guido argued
for having Zope's interfaces be in s subpackage (or have a weird name)
specifically to make it easier to add a standard interface package later,
assuming that a standard package might not be exactly the same as Zope's.
I understand the desire to carve out a package namespace that z3 can
reliably use without risk of collision with other packages.  I still
think that's less of a practical concern in the Python world
We've had colisions in the past. That's why we're being careful now.

(BTW, I think it was a mistake to have top-level persistent and transaction
packages. I think that will eventually come back to haunt us.)
The only way to avoid collissions is to pick stupid names (zthis, zthat).
I much prefer z.this to zthis. This assumes that we can make it easy to
install z.this into z.
 so I'd opt
for an approach that gets the non-Zope specific technologies into the
most hands of Python programmers.
I think that that's a different discussion.  The safest thing to do
for now is to continue using a container package.
Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Barry Warsaw
On Thu, 2004-04-15 at 10:23, Jim Fulton wrote:

 Each separately distributed package will have a DEPENDENCIES.cfg that is
 created by hand and that *constrains* dependencies on other packages. It
 makes explicit the intended dependencies. Dependencies not listed here
 are bugs.  Adding depenencies to this file should be considered a big deal.

That's very comforting!  I like that it forces developers to be
deliberate when adding cross-subpackage dependencies.

-Barry



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: [Zope-dev] ZPT in Zope Products

2004-04-15 Thread Wyatt Anderson
This does not work either.  With this I get the following traceback:

Traceback (innermost last):
  Module ZPublisher.Publish, line 100, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 40, in call_object
  Module Products.MyContainer.MyContainer, line 17, in
manage_addMyContainerForm
  Module Shared.DC.Scripts.Bindings, line 306, in __call__
  Module Shared.DC.Scripts.Bindings, line 341, in _bindAndExec
  Module Shared.DC.Scripts.Bindings, line 1, in ?
  Module Shared.DC.Scripts.Bindings, line 286, in _getTraverseSubpath
AttributeError: 'str' object has no attribute 'other'

return pt

works with incorrect results...displays PageTemplateFile at
containerError

return pt.document_src()

works to the extent that it actually displays what's in the ZPT but does
not render any of the TAL.

return pt.pt_render()

does not work causing the traceback from my original message.

return pt()

gives me the above traceback.

Unfortunately I cannot find any good documentation on ZPT.  I could
give up and do my checking in the ZPT itself but this does not lead
to reusability.  BTW, using Zope 2.7.

Anyone out there with an example of how they've used page templates
in a product?

Thanks,
Wyatt

-Original Message-
From: Santi Camps [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 15, 2004 4:26 AM
To: Wyatt Anderson
Cc: [EMAIL PROTECTED]
Subject: Re: [Zope-dev] ZPT in Zope Products

Wyatt Anderson escribió:

 Hello All,

 I am trying to use ZPT within a Zope Product I am trying to build.

 I want to test the container type I am addding to to determine what

 action to take. The following though

 from Products.PageTemplates.PageTemplateFile import PageTemplateFile

 def manage_addMyContainerForm(self, REQUEST):

 pt = None

 if self.meta_type in [‘ContainerType1’, ‘ContainerType2’]:

 pt = PageTemplateFile(‘zpt/addMyContainerForm’, globals())

 else:

 pt = PageTemplateFile(‘zpt/containerError’, globals())

 return pt.pt_render()

 This produces the following traceback in Zope:

Traceback (innermost last):

  Module ZPublisher.Publish, line 100, in publish

  Module ZPublisher.mapply, line 88, in mapply

  Module ZPublisher.Publish, line 40, in call_object

  Module Products.MyContainer.MyContainer, line 17, in
manage_addMyContainerForm

  Module Products.PageTemplates.PageTemplate, line 90, in pt_render

   - PageTemplateFile at containerError

  Module Products.PageTemplates.PageTemplateFile, line 73, in
pt_getContext

TypeError: 'str' object is not callable

 I’ve checked out the code in PageTemplate.py and PageTemplateFile.py 
 and can’t

 figure out what is going on. The line in question is

 root = self.getPhysicalRoot()

 Is it possibly some security thing? My class is 
 setDefaultAccess(‘allow’) for now.

 I’ve also tried simply

 return pt

 with no traceback but without the desired results as the object is 
 returned.

 Thanks in advance,

 Wyatt

Try return pt()

Santi Camps

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] ZPT in Zope Products

2004-04-15 Thread Clemens Robbenhaar

Hi Wyatt,

  from Products.PageTemplates.PageTemplateFile import PageTemplateFile
   
  def manage_addMyContainerForm(self, REQUEST):
pt = None
  if self.meta_type in ['ContainerType1', 'ContainerType2']:
  pt = PageTemplateFile('zpt/addMyContainerForm', globals())
else:
  pt = PageTemplateFile('zpt/containerError', globals())
return pt.pt_render()

I guess the problem is that the page template file is called without
acquision context. Usually a page template file is a class attribute of
a class which knows about acquisition.

You could mange in the right context via 

 return pt.__of__(self).pt_render()

but I am not sure if this will fly.

Cheers,
Clemens

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Barry Warsaw
On Thu, 2004-04-15 at 11:39, Casey Duncan wrote:

 Additionally (and Jim and I have discussed this amongst ourselves) I
 feel strongly that the dependancies should be enforced by tests. 

Good point.

 The dependancy tests might need to be separate from unittests because
 they would probably require an import hook or somesuch. Perhaps a tool
 like pychecker could be leveraged or extended to provide this service.
 At a minimum this test would need to be run before packaging a
 distribution, but ideally would happen more often.

I wonder if some kind of doctest could be added to the __init__.py of
the package that hooked __import__ and then attempted to import each
module in the package, tracking the imports.  Then complain about
anything not defined in DEPENDENCIES.cfg (and hmm, what to do about
standard library imports?).

Yeah, maybe some kind of pychecker hook would be better. :/

-Barry



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Stephan Richter
On Thursday 15 April 2004 11:39, Casey Duncan wrote:
 Additionally (and Jim and I have discussed this amongst ourselves) I
 feel strongly that the dependancies should be enforced by tests. That
 is, if you introduce and errant dependancy (by adding an import to a new
 package not in the stdlib or DEPENDANCIES.cfg) that it break a
 dependancy test.

I think this can be easily done using the finddeps.py utility. I think the 
hard work of finding all the dependencies in the first place is done. Note 
that Zope can also have dependencies in its ZCML files (which is handled by 
finddeps.py).

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Martijn Faassen
Stephan Richter wrote:
On Thursday 15 April 2004 11:39, Casey Duncan wrote:

Additionally (and Jim and I have discussed this amongst ourselves) I
feel strongly that the dependancies should be enforced by tests. That
is, if you introduce and errant dependancy (by adding an import to a new
package not in the stdlib or DEPENDANCIES.cfg) that it break a
dependancy test.


I think this can be easily done using the finddeps.py utility. I think the 
hard work of finding all the dependencies in the first place is done. Note 
that Zope can also have dependencies in its ZCML files (which is handled by 
finddeps.py).
Note that for checking dependencies in Python code I still think this 
tool could be improved by using technology from importchecker.py

http://cvs.zope.org/Zope3/utilities/importchecker.py

which can use Python's compiler module to lift all imports from source 
code, which I think is safer than the hand crafted parser approach 
finddeps.py takes now.

If somebody lets me know which API they want implemented for retrieving 
imports (and use of imports) I could do this lifting work myself.

Regards,

Martijn

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Stephan Richter
On Thursday 15 April 2004 13:22, Martijn Faassen wrote:
 Note that for checking dependencies in Python code I still think this
 tool could be improved by using technology from importchecker.py

 http://cvs.zope.org/Zope3/utilities/importchecker.py

 which can use Python's compiler module to lift all imports from source
 code, which I think is safer than the hand crafted parser approach
 finddeps.py takes now.

 If somebody lets me know which API they want implemented for retrieving
 imports (and use of imports) I could do this lifting work myself.

Fred has fixed that a while ago already (if I read the checkins 
correctly). :-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev], [Zope-dev] More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Fred Drake
On Thursday 15 April 2004 10:23 am, Jim Fulton wrote:
  (BTW, I think it was a mistake to have top-level persistent and
  transaction packages. I think that will eventually come back to haunt us.)

I won't disagree with this.  ;-(

  The only way to avoid collissions is to pick stupid names (zthis, zthat).
  I much prefer z.this to zthis. This assumes that we can make it easy to
  install z.this into z.

As long as z gets installed *at all* (before/after is not an issue), we can do 
this now.  This is supported, if only by accident, by the current 
implementation of distutils.

  I think that that's a different discussion.  The safest thing to do
  for now is to continue using a container package.

I like this as well.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope3-dev], [Zope-dev] Import checking code

2004-04-15 Thread Fred Drake
On Thursday 15 April 2004 13:22, Martijn Faassen wrote:
  Note that for checking dependencies in Python code I still think this
  tool could be improved by using technology from importchecker.py
...
  which can use Python's compiler module to lift all imports from source
  code, which I think is safer than the hand crafted parser approach
  finddeps.py takes now.

I keep meaning to get back to you about this; sorry it's taken me so long.

I wrote the tokenize-based code before I saw your importchecker.py code; I'd 
decided to go with the tokenize module instead of the compiler package since 
the later was poorly documented (IMHO).  I've no really strong feeling about 
either approach being better.

  If somebody lets me know which API they want implemented for retrieving
  imports (and use of imports) I could do this lifting work myself.

I'm not sure simply re-implementing one of the finddeps.py internal interfaces 
is the right thing to do; that's some incredibly cludgey code in Zope 3.  
There's a lot of confusion about what values are paths and which are module 
names, and that makes me very uncomfortable.

If you'd like to replace the code that locates imports, feel free to do so.  
It may be that conciseness wins; the tokenize-based approach certainly ended 
up being more code than I'd expected initially.

On Thursday 15 April 2004 01:21 pm, Stephan Richter wrote:
  Fred has fixed that a while ago already (if I read the checkins
  correctly). :-)

No, Martijn's talking about something else... kinda.  I imagine he had even 
stronger feelings about your initial implementation.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Martijn Faassen
Stephan Richter wrote:
On Thursday 15 April 2004 13:22, Martijn Faassen wrote:

Note that for checking dependencies in Python code I still think this
tool could be improved by using technology from importchecker.py
http://cvs.zope.org/Zope3/utilities/importchecker.py

which can use Python's compiler module to lift all imports from source
code, which I think is safer than the hand crafted parser approach
finddeps.py takes now.
If somebody lets me know which API they want implemented for retrieving
imports (and use of imports) I could do this lifting work myself.


Fred has fixed that a while ago already (if I read the checkins 
correctly). :-)
Well, perhaps I missed something. It changed to use the Python 
tokenizer, I think, if it wasn't doing this already. It doesn't use the 
compiler module, as importchecker does Anyway, I guess the tokenizer is 
fine too, and might even be faster for all I know, just seems an 
unfortunate duplication of work, plus I checked in importchecker for 
little reason. :)

Regards,

Martijn

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-15 Thread Shane Hathaway
On Thu, 15 Apr 2004 [EMAIL PROTECTED] wrote:

 What happens is you write a new serializer, notably write a custom
 serializer for an object type you've already been using for a while, using
 the default one ? (Presumably because you WANT to be able to access the
 contents from other tools)
 
 I think I noticed that somewhere in the .properties file there was a note of
 the class used for serializing ... Is there a way for a serialized instance
 to remember which serializer was used ? Or does everything break when I
 change the definition of a serializer (Old instances can no longer be read)
 ?

Ape has a solution.

Every object is stored with a classification.  The classification (a
dictionary of strings, stored in whatever format is chosen by apeconf.xml)  
has at least two keys: class_name and mapper_name.  The mapper_name tells
Ape which mapper was used to store the object, enabling Ape to reliably
use the same mapper to load the object later.  The class_name is used by
mappers that work with multiple classes.

When Ape stores a new state for an object previously loaded, it disregards
the earlier choice of mapper.  So, for example, lets say you've made a
class called UltraPageTemplate, which subclasses ZopePageTemplate.  If you
store that using the default configuration, Ape won't try to guess how you
meant to store it and will mostly just pickle it.  The mapper_name will be
anyfile.

Later, you add to apeconf.xml a mapper that specifically serializes
UltraPageTemplate objects, using the mapper_name
Products.UltraPT.UltraPT.UltraPageTemplate.  Ape will continue to load
UltraPageTemplates stored using the anyfile mapper because the
mapper_name supercedes the class_name when loading.  However, when you
store new UltraPageTemplates or update existing ones, Ape will use your
new mapper, since the old choice of mapper is not consulted at save time.  
Therefore, to update all existing instances of UltraPageTemplate to use
your new mapper, you only need to get ZODB to load all the existing
instances and store them again unchanged.  If your new mapper is 
complete, the old pickles will go away and people will be able to edit 
UltraPageTemplates outside Zope.

Using strategies like this, Ape is trying to achieve a mode of development
that doesn't require you to decide how to store objects at the same time
you write classes.  You start with ZODB, a radically simple, unintrusive
storage layer, then you customize gradually with Ape.  I think Ape is 
making good progress toward that goal.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)

2004-04-15 Thread Shane Hathaway
On Wed, 14 Apr 2004, Kapil Thangavelu wrote:

 although i wonder if there is some hand waving in progress here that i
 can't see. i guess my semantic notion of versions has been that of long
 lived transactions, and is there a better means of thinking of them? how
 do they play across with multiple mounted zodbs? what would something
 like merge mean in the context of a catalog?

By my understanding, outside the storage, different versions are
completely independent.  You could even simulate multiple databases using
versions.  It is the storage that knows how to create new versions, merge
versions, and prevent objects being used in a version from being changed.

Mounted databases try to use the same version as the root connection.

To merge a catalog, you could bring one of the stored catalogs to life
within the storage and replay the sequence of transactions that occurred
in the other catalog.  This could be tricky, and opening a catalog within
a ZEO server would make the ZEO server less stable.

I think there might be other ways to look at it.  One way to simplify
would be to put catalogs in their own storage, separated from the content
they index.  That way, you could (ab)use the transaction machinery to
abort or commit indexes as you see fit within the catalog conflict
resolver.  I've experimented with this before, and it seemed promising.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )