(I think) rather than use fssync to export multiple 'sites' in a single Zope
instance, I'd much rather have multiple ZODB file storage instances -- i.e. one
Data.fs for each site. I have no requirement to share points or UI across these
sites -- I just want to eliminate having to run a separate
profound
implications for TTW development. Would this not alleviate the SCM problerms of
code-in-the-ZODB-black-box syndrome that Zope 2 faces?
-- Garrett
On , [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
I have a backup requirement to save a folder (a site) and be able to
restore it without
On , [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
I can spend some time on the command line tool -- that
would be ideal for us anyway. Security isn't an issue, at
least short term, as this is strictly for OS-level backups.
In the next couple weeks I'll take a closer look.
Great! Thanks
Is anyone interested in using export/import capabilities in Zope 3?
As we get more Zope 3 deployments, I think this will become an important topic.
It looks like the fssync code has become only slightly stale. With a little
use, this could be break-out feature for Zope 3 developers.
As Jim
On , [EMAIL PROTECTED] wrote:
Hi together
Behalf Of Fred Drake
Sent: Friday, September 23, 2005 4:13 AM
To: Gary Poster
Cc: Garrett Smith; zope3-dev
Subject: Re: [Zope3-dev] browserDefault uses '@@' for containers
On 9/22/05, Gary Poster [EMAIL PROTECTED] wrote:
I believe
Why does z/a/container/traversal/ContainerTraversal include '@@' in the default
view name? This is not the case in SimpleComponentTraverser
(z/a/publication/traversers). Is there something special about containers that
their default view should be an explicit view lookup? Or should
Sorry for the long delay in replying.
We've been using widget-specific JS and CSS for some time now and I like our
approach. It's quite different from the proposal.
We're using the same pattern used by forms/widgets -- i.e. the PT is
responsible for explicitly including HTML fragments provided
I don't understand what you just said :-)
My fault -- I haven't been plugged into the other discussion.
Is there a branch somewhere that has a simple demo to help with grokability?
-- Garrett
On Friday, September 16, 2005 12:28 PM, Gary Poster wrote:
On Sep 16, 2005, at 12:49 PM, Garrett
On Friday, September 16, 2005 3:15 PM, Benji York wrote:
Garrett Smith wrote:
I don't understand what you just said :-)
My fault -- I haven't been plugged into the other discussion.
Is there a branch somewhere that has a simple demo to help with
grokability?
http://www.zope.org/Wikis/DevSite
On Friday, September 16, 2005 4:05 PM, Benji York wrote:
Garrett Smith wrote:
If it's just a patch to get 'rich' widgets working, I'll stick with
my initial impression of it being too magical.
The main reasons why this isn't a problem individual widgets
can solve
is that 1) they can't
in the
HEAD.
-- Garrett
On , [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
That's right. But the view can solve these problems easily without a
lot of other stuff like yet-another-ZCML directive and automagical
transformation of the HTML head element.
This is what we have:
class
On Friday, September 16, 2005 3:58 PM, Gary Poster wrote:
You could also be asking about the pipeline ideas, but that's not my
first guess. :-)
Yes, I suspect this is what I'm missing.
There was an earlier post about Ajax. It seems an entirely new approach would
be needed to solidly support
I ended up using 'type' to create a new proxy with a dynamically created
__slots__. I haven't run into any weirdness with that approach, so far :)
-- Garrett
-Original Message-
From: Jim Fulton [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 9:03 AM
To: Garrett Smith
Cc
I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic. This would add more. The whole
concept of initial value seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters
I'd like to create a proxy where __slots__ is determined (or appended to) when
the proxy is constructed. E.g.
foo = Foo()
bar = SomeProxy(foo, 'baz')
bar.baz = 123
hasattr(foo, 'baz')
False
hasattr(bar, 'baz')
True
Is it possible to do this?
-- Garrett
I think a post to this list is fine.
-- Garrett
On Jul 31, 2005, at 8:32 AM, Julien Anguenot wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Where would be the best place for this migration notes ?
J.
Garrett Smith wrote:
It's clear that NotFoundError is deprecated, but I'm
On the outside chance this effects you, PrincipalInformation should now be
spelled InternalPrincipal.
(Deprecation warnings had not been added for this BBB class, so its deletion
may catch some by surprise.)
-- Garrett
___
Zope3-dev mailing list
This affects anyone who has created a custom authenticator search UI (and if
there's anyone who has done this, consider yourself a hyper super power user!)
PAU queriables are now looked up by adapting an authenticator AND the PAU
(prior to the recent change, only the authenticator was adapted).
Is there any info published on debugging Zope3 deadlocks? I'd like to see
tracebacks of a couple threads. Has anyone done this w/Zope3?
-- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
I'm getting mail from this list from
[EMAIL PROTECTED]
We just moved to a different mail server -- the word 'bounces' would seem to be
a bad thing (yet I'm still receiving posts from the list).
Does anyone know why I'm getting mail in this way?
-- Garrett
That application of the user's timezone might be done before the
datetime is actually generated, or with a datetime.replace
(tzinfo=ITZInfo(request)) call. (The immutable nature of strings,
datetimes, and other similar types doesn't prevent us from
performing
operations with them or
-Original Message-
From: Fred Drake [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 21, 2005 12:25 PM
To: Garrett Smith
Cc: Zope3-Dev (zope3-dev@zope.org)
Subject: Re: [Zope3-dev] Formatting dates
On 7/21/05, Garrett Smith [EMAIL PROTECTED] wrote:
I guess my question
'.
-Original Message-
From: Gary Poster [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 19, 2005 11:47 AM
To: Garrett Smith
Cc: Zope3-Dev (zope3-dev@zope.org)
Subject: Re: [Zope3-dev] Formatting dates
On Jul 19, 2005, at 12:22 AM, Garrett Smith wrote:
Now that dates have UTC time
This might be something on my end, but I figure I'd throw it out in case it's
related to any changes related to naïve/non-naïve time zones.
Here's the relevant part of the traceback:
File /opt/aktari/zope/src/zope/i18n/format.py, line 175, in format
info = buildDateTimeInfo(obj,
Now that dates have UTC time zones associated with them, will we be adjusting
how they're displayed in various views? Somehow it doesn't seem appropriate to
display UTC by default. I'd assume Zope would use the server's timezone offset.
-- Garrett
This change has broken presisted SessionCresentials. I'm not sure why,
but the unpickler is calling SessionCredentials __init__.
I'm not sure what the right course is here, but I think something should
be done. One of these perhaps:
- Revert to old style class
- Write a conversion script
-
I'd like to be able to grant permission to traverse a folder, but not
permission to view folder contents.
This could be handled in Zope by making
container.traversal.ItemTraverser a trusted adapter and protecting it
with a zope.Traverse permission.
I suspect this problem has been discussed
Jim Fulton wrote:
Garrett Smith wrote:
The use of INameChooser is useful for picking names that don't
conflict across serial transactions. But this approach is
problematic when two or more transactions are tying to add objects
to a container at the same time. Because 'choose name' relies
Roger Ineichen wrote:
pluggableauthentication utility
Hi Garrett
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 18, 2005 7:52 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: zope3-users@zope.org; zope3-dev@zope.org
Subject: RE: [Zope3-dev] Utility Registration
The use of INameChooser is useful for picking names that don't conflict
across serial transactions. But this approach is problematic when two or
more transactions are tying to add objects to a container at the same
time. Because 'choose name' relies on its isolated version of a
container, multiple
Jim Fulton wrote:
Garrett Smith wrote:
:-) I guess this approach is *so* endemic to Zope 3, I must be
missing something huge.
What we're talking about is not very different from the way that
composition is used to prevent explosition of field types.
For example, we use: List(Int
Garrett Smith wrote:
Jim Fulton wrote:
Garrett Smith wrote:
:-) I guess this approach is *so* endemic to Zope 3, I must be
missing something huge.
What we're talking about is not very different from the way that
composition is used to prevent explosition of field types.
For example, we
Jim Fulton wrote:
Uwe Oestermeier wrote:
...
Alternatively, all mentioned usages could be easily subsumed under
an extended ObjectModifiedEvent definition. Some optional keywords
(for the interface and the attribute that was used to change the
object, and additional infos about the changed
Uwe Oestermeier wrote:
...very good analysis of current modified event usage...
Alternatively, all mentioned usages could be easily subsumed under an
extended ObjectModifiedEvent definition. Some optional keywords (for
the interface and the attribute that was used to change the object,
and
Uwe Oestermeier wrote:
Garrett Smith wrote:
I'd see this being something like a ValueChangedEvent that specified
the object, schema, field name, old value, and new value. This would
be a nice way to bolt on validation without modifying the schema.
Yes, that's exactly what I need
From the interface docs, it's not clear to me what the difference
between the events are:
class IObjectModifiedEvent(IObjectEvent):
An object has been modified
class IObjectContentModifiedEvent(IObjectModifiedEvent):
An object's content has been modified
What is the difference between
We currently dispatch some object events to sublocations. I think
there's a problem with the current approach.
If I subscribe to IObjectModifiedEvent with something like this:
def handle(object, event):
...
I'll get notifications where object and event.object are different. This
Gary Poster wrote:
On May 3, 2005, at 5:39 PM, Garrett Smith wrote:
We currently dispatch some object events to sublocations. I think
there's a problem with the current approach.
...
Why not just have your own app listen for (object, event) and then do
this additional dispatch? That's
Uwe Oestermeier wrote:
But I could also live with ObjectModifiedEvents only.
IMO, the second event type, if it doesn't have a clear distinction,
should be removed.
A more radical approach would be to specify in each
ObjectModifiedEvent which aspects of an object changed. By aspect I
mean the
Jim Fulton wrote:
I'd like to make some changes to the widget API.
http://www.zope.org/Zope3/MoreCleanupOfWidgets
proposes some cleanup, but I'd like to go farther.
I think widgets, especially IInputWidget have too much
responsibility, namely:
- validation
- applying changes
Jim Fulton wrote:
This is for people who've implemented ZODB data managers. Data
managers are components that manage persistent data under transaction
control,
We've recently tried to clean up and document the data-manager
interfaces. In addition, over the weekend, I implemented
Jim Fulton wrote:
Garrett Smith wrote:
Recent changes to the transaction management API seem to have come
out of the blue and without warning. Perhaps I missed an
announcement.
Are we to expect breakages of this sort on occasion?
Was there breakage? If there was, it was unintended
Tim Peters wrote:
[Jim Fulton]
Was there breakage? If there was, it was unintended.
[Garrett]
IDataManager was completely restructured.
This was not accurate -- the restructuring happened a while ago and I
didn't catch it. I assumed this change was made along with the one I
list below.
If
Adam Groszer wrote:
I'm trying to build install the Zope 3 trunk on Win2K.
I'm having some problems with it.
May I post them here or is it too early for the upcoming release?
Adam
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
Jim Fulton wrote:
A recent simplification was made to adapter and utility registration.
When registering adapters, the provided interface can be ommitted
if the registered factory implements a single interface. Similarly,
when registering utilities, the provided interface can be ommitted
if
Jim Fulton wrote:
Garrett Smith wrote:
I don't understand the pushback against location proxying
security-proxied objects. LocationProxy does actually play well with
security-proxied objects.
That was not our experience in the recent past. I'll have to document
the problems, assuming
46 matches
Mail list logo
