At 04:04 PM 5/18/00 -0400, Dan L. Pierson wrote:
The portal now gets created, but I can't login to the initial account.
I also can't display the members roster by clicking on Members
(AttributeError for getUsers), but can write a DTML method in the
UserSource that lists all one user. The code
At 03:51 PM 5/21/00 -0400, Tres Seaver wrote:
This is really just the classic Observer pattern, a la GoF Design
Patterns. "ObjectAdded" and "ObjectRemoved" are events a
"RackObserver" would register for; "AfterCreate", "Changed",
and "BeforeDestroy" are events of the "hosted" object itself.
At 05:33 PM 5/24/00 +0400, Jephte CLAIN wrote:
Hello,
I believe items got from a rack have to be wrapped in context of the
rack. I've been bitten by this (and it hurts!). When I try to use items
from DTML, only the superuser can use it, even managers can't access the
objects. When I wrap the
At 05:24 PM 5/24/00 +0300, Itamar Shtull-Trauring wrote:
"Phillip J. Eby" wrote:
Make your root acl_users a LoginManager, with the loginForm there.
LoginManager will only allow "Anonymous" to log in if it is the root
acl_users. This is how standard user folders behave, a
At 07:19 PM 5/24/00 -0400, Tres Seaver wrote:
I have started a page for an implementation of the GangOfFour Observer
pattern within Zope:
URL
http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotificat
ion
Please comment, either here or in the wiki.
Is this only for events
At 01:56 PM 5/25/00 +0400, Jephte CLAIN wrote:
When I don't wrap items like this, I get strange unauthorized errors.
Only the super user can use the items. All the other users (Managers or
not) can't.
In normal usage, one only accesses a rack from or in a Specialist.
Specialists wrap the
At 12:45 AM 5/25/00 -0400, Tres Seaver wrote:
Ah, ok -- I was planning simply to leverage the ZODB's facilities for
maintaining persistent references in the DefaultObservable mix-in; more
elaborate schemes would be possible (for instance to support
rack-mounted observers?)
Actually, just using
At 10:03 AM 5/26/00 +1000, Anthony Baxter wrote:
"Phillip J. Eby" wrote
I would suggest that it ask for an interface, rather than a meta_type.
Otherwise, you've hardwired yourself into a single object type with no
extensibility. For example, an SQL method wants the nearest SQL
At 03:05 PM 5/26/00 -0400, Evan Simpson wrote:
- Original Message -
From: Phillip J. Eby [EMAIL PROTECTED]
Been there, done that. Yours doesn't work either, btw. Well, actually,
it
does, it's just that it causes a memory leak because it leaves an
unintended circular reference. We've
At 06:14 PM 5/26/00 -0400, Evan Simpson wrote:
D'oh! How 'bout if REQUEST.close() were to always do a
self.__dict__.clear()?
Are you absolutely positively sure that REQUEST.response is never accessed
following REQUEST.close()? In my cursory examination of the code paths, I
wasn't sure that
At 12:53 PM 5/30/00 +0300, Itamar Shtull-Trauring wrote:
I've been playing around with ZPatterns, and I must say it's very cool -
finally you can mix ZCatalog and SQL storage. CatalogAwareness is slightly
different than regular Zope objects in that you have to find the ZCatalog in
the Rack's
At 01:40 PM 6/2/00 +0800, Mike wrote:
As I'm reading ZPatterns source code more and more I'm finding there are
good things just hidden in unclean or bad defined interfaces. Just a
suggestion: define interfaces as abstract classes first, then implement
them (as AbstractRack, DefaultRack and
At 01:51 AM 6/2/00 -0600, Bill Anderson wrote:
"Phillip J. Eby" wrote:
[...]
LM 0.8.6 also works with Zope 2.2 as far as being able to be added,
although I'm not sure it interoperates properly with the new security API.
It will still be backward compatible with Zope 2.1.6 either w
At 06:31 PM 6/10/00 +0800, Mike wrote:
Maybe the best way is to put a 'thumb' data source into Customers
instead of native one. This thumb should translate all messages to
SkyDivers' data source.
Yes, a "Delegation Rack" is certainly possible. It would make it really
easy to merge data from
At 04:22 PM 6/11/00 -0400, Kevin Dangoor wrote:
What will be the right way to subclass ObjectManager? CatalogAware won't
really be necessary, because you can use the events stuff to catalog
things... but, I make a lot of things ObjectManagers...
All that's required is that manage_afterAdd call
At 12:06 PM 6/13/00 -0600, ethan mindlace fremen wrote:
Ok, lighter grey less blue bars. Also simply asking for more products will
hide the DC products, as opposed to having to sort (which still works)
Whitespace between entries, please, and an indent of the description would
be nice. It's
At 12:42 PM 6/15/00 -0400, Shane Hathaway wrote:
Agreed; I see this as by far the best approach. It's a tried and true
pattern.
Not only that, but it gives you extremely fine-grained control over what
you do and don't log. And, if the other events like adds and deletes on
folders are in
At 01:40 PM 6/15/00 -0700, Loren Stafford wrote:
Where is Observer-Observable in the development plan? ZPatterns 0.4?
-- Loren
No. 0.4 is targeted for 2.1.6 compatibility, and Observable will require
Zope 2.2's new Traverse features. Also, 0.4 is due out tomorrow and I'm
way behind on
At 11:33 AM 6/19/00 +0300, Itamar Shtull-Trauring wrote:
As far as I can tell, the first time an object is changed, an Agent's
_objectChanged() will be called, but as long as the object is still in the
memory cache, _objectChanged() will not be called again.
_objectChanged is a once per object
At 08:44 PM 6/19/00 +0800, mike wrote:
Fix for www/storageForm.dtml
$ diff storageForm.dtml.orig storageForm.dtml
7c7
FORM METHOD="POST" ACTION="manage_setStorage"
---
FORM METHOD="POST" ACTION="."
56c56
brINPUT TYPE="SUBMIT" value=" Change Storage Settings"
---
brINPUT
At 08:12 PM 6/19/00 +0800, mike wrote:
Another bug I found (file Rack.py):
def createItem(self,key):
# Create a new object, identified by key
item = self.getItem(key)
# XXX What if all items potentially exist?
if item is not None:
raise
0.4.0a2 is out, to fix the bugs reported by Itamar and Mike. I have not
yet reproduced all the bugs Mike has reported, but here's what's fixed in
alpha 2:
* The missing _objectChanged() message - it was very hard to track down,
because everything appeared to be working right, except for the
At 11:54 AM 6/20/00 +0300, Itamar Shtull-Trauring wrote:
"Phillip J. Eby" wrote:
* The missing _objectChanged() message - it was very hard to track down,
because everything appeared to be working right, except for the fact that
it wasn't working. Turns out that _v_status_ (th
At 08:58 PM 6/19/00 +0800, mike wrote:
http://www.zope.org/Members/RainDog/ZSession/ZSession-0.0.2.tar.gz/view
Comments?
Now that I've had a chance to really look at this (while tracking down one
of the bugs you found), I do have a few comments.
First, nice job... It's a good adaptation use
At 10:25 PM 6/20/00 +0800, mike wrote:
"Phillip J. Eby" wrote:
Huh? Oh, %#()@%... I fixed that in my working copy, but didn't check it
into CVS before building a release .tgz yesterday... Argh. Line 137 of
DataSkins.py *should* read:
if self._v_status_ is not Cha
At 10:51 PM 6/20/00 +0800, mike wrote:
"Phillip J. Eby" wrote:
example. Think of someone creating a Session subclass called "Shopping
Cart", with methods for viewing, checking out, adding/deleting items, etc.
Or, if they have many subsystems which want to share the s
At 05:49 PM 6/20/00 +0300, Itamar Shtull-Trauring wrote:
Huh? Oh, %#()@%... I fixed that in my working copy, but didn't check it
into CVS before building a release .tgz yesterday... Argh. Line 137 of
DataSkins.py *should* read:
Great, it works!
Tell me, were you able to use
At 01:06 PM 6/23/00 +0800, mike wrote:
There _IS_ a problem. Maybe _v_cachedAttr is not a guilty, but do you
know it exists only in newly created objects and do _not_ exists in
old?.
The attribute cache is created only when used in a transaction, so if you
retrieve a persistent object from a
At 01:58 PM 6/15/00 +1000, Stuart 'Zen' Bishop wrote:
Its not a problem with ZScheduler, it a problem that no one has written
a plug-in logging system that is good enough for what you are trying to
do. The existing zLOG API is fine (well - it could be better), but just
needs someone to write the
At 01:08 PM 6/26/00 +0400, Jephte CLAIN wrote:
This code should (IMHO) read:
def getItem(self, key):
if hasattr(self.aq_base,'retrieveItem'):
return self.retrieveItem(key=key) # XXX need DTML check?
for rack in self.rackList:
item = rack.__of__(self).getItem(key)
At 11:54 AM 6/27/00 +0400, Jephte CLAIN wrote:
mike wrote:
There is no way to infinite recursion if Rack.getItem is leaved
untouched.
Ah ah. But people will touch it. Like me for example :-)
There is no way to prevent overriding getItem from a ZClass for example.
And it *will* recurse
By all means, feel welcome. I've been on vacation a while.
At 02:29 PM 6/28/00 +0100, Steve Alexander wrote:
I just looked over the ZPatterns Wiki for Shane's explanation, but I
can't find it.
If it isn't there (hiding somewhere), perhaps I can add it from Shane's
original email?
At 03:10 PM 6/28/00 +0100, Chris Withers wrote:
1. Too much jargon... by far... Lots of complicated words that are
meanlingless to the layman and don't help to convey the concepts.
Yep, like "Acquisition" and "object publishing". :) Seriously, that is
very much the level we're talking about
At 10:06 AM 7/3/00 -0500, Steve Spicklemire wrote:
Seriously, I'm trying to get it all figured out, and I thought maybe
if I attempted to do something 'real' with it I would at least learn
what I *don't* understand. Well.. I've learned a *lot*! (about what I
don't understand.. ) ;-) The source
At 05:26 PM 6/28/00 +0100, Steve Alexander wrote:
The suggested specialists in the Accounting framework are:
Invoices
Orders
Customers
Products
What I'm finding is that these are just the White-box specialists. A
clean design would seem to want all the specialists above, plus at least
At 11:54 AM 7/3/00 +0100, Chris Withers wrote:
Just a quickie:
If, as the the ZPatterns Wiki states, 'Specialists are not classes',
then why is there a 'Specialist' python class in the ZPatterns
distribution?
Specialists are instances of the class "Specialist". They are not
themselves
At 02:21 AM 7/5/00 +, Scott Parish wrote:
Does anybody out there have even the slightest clue about how to go about
using AttributeProviders and SheetProviders? A select few terse hints on
this subject would really help us (me) figure it out enough to start working
on some howto's.
You
At 03:12 PM 7/5/00 -0500, Jimmie Houchin wrote:
"Phillip J. Eby" wrote:
[snip]
Peter Coad's design approach (which ZPatterns is heavily based on/biased
towards) emphasizes four major layers of classes in an application:
1) User Interface (GUI, forms, etc.)
2) Problem Domain (
At 12:01 PM 7/5/00 -0400, Shane Hathaway wrote:
Itamar Shtull-Trauring wrote:
I propose a Restricted Creation Interface - when an ObjectManager
constructs
it's Add list in manage_main, it first checks with each addable class if
it's instances can be added in this specific ObjectManager.
The
At 01:58 PM 7/5/00 +0300, Itamar Shtull-Trauring wrote:
Are there (or better yet, what are) any potential problems here? My gut
feeling was that it wouldn't work, but you can at the very least add objects
in instances of the ZClass - deleting and renaming don't work though.
When you say
At 11:14 AM 7/5/00 +0400, Jephte CLAIN wrote:
Hello,
I use virtual attribute access to provide access to my SQL database.
However, I want to use the Rack.newItem facility to create new records
in the database.
But it fails because in virtual mode, an item always exists.
This patch solves the
At 09:21 PM 6/28/00 +, Ty Sarna wrote:
In article [EMAIL PROTECTED],
Shane Hathaway [EMAIL PROTECTED] wrote:
Ok folks,
I thought I had made it clear that this problem has been solved. I have
sent a patch to Ty (about two weeks ago) as well as made the change in
Sorry for the delay.
At 12:38 PM 7/9/00 -0500, Steve Spicklemire wrote:
pje None of the above. SkyDiver should inherit from a Party base
class. For
pje Customer and ResourceUser behavior, one adds propertysheets whose
class is
pje provided by the respective frameworks. This is extension through
At 01:37 PM 7/9/00 -0500, Steve Spicklemire wrote:
Thanks Steve,
Eegads! OK... all my instances currently live in a defaultRack of one
specialist or another... so exactly how do I "configure this
DataManager to provide the PropertySheets (I) want, with sensible
default values, and suddenly, all
At 04:40 PM 7/9/00 -0500, Steve Spicklemire wrote:
Wow.. alright. I think I need "ZPatterns for Dummies" or maybe there
needs to be a disclaimer "ZPatterns are NOT for Dummies." ;-)
I've pretty much given up on Sheets for now. Nothing I've tried
has actually worked. I thought maybe I needed to
At 10:02 AM 7/10/00 -0400, Shane Hathaway wrote:
Phillip,
What if the management interface for specialists provided a way to
manipulate, or at least view, the table of virtual objects (or, in
ZPatterns-speak, DataSkins)? Wouldn't that make ZPatterns more
accessible?
Probably. The sticking
At 03:07 PM 7/10/00 -0400, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
Understood. I'll try to keep that use case in mind. Keep in mind,
however, that being able to create a LoginManager is a pretty risky
business in a portalish environment - you could potentially
At 02:29 PM 7/10/00 -0400, Shane Hathaway wrote:
I decided to try out this idea. It turned out to be a cinch! It
doesn't restrict the manage_* methods yet; I'll get to that after I get
some feedback. Thoroughly untested except on my box; use at your own
risk, etc. :-)
FYI, I entered a Collector feature request for this over the weekend; I
classified it as "somewhat important/future", IIRC. It mentions the "set
up two accounts" concept you describe below, and I think there might be
some other notes as well.
At 05:07 PM 7/10/00 -0400, Shane Hathaway wrote:
I found this one on Saturday. The problem is that Zope recently changed
the way constructors bind to their factory objects, and the "self" that
ZPatterns is providing to the constructors is no longer needed. I've
changed ZPatterns to fix this (still maintaining 2.1.x compatibility in the
in
locally and will incorporate it into a release soon.
At 04:09 PM 7/12/00 +0100, Steve Alexander wrote:
Steve Alexander wrote:
"Phillip J. Eby" wrote:
This would explain why you only get a change event, since if add happens
after change, it is ignored. I'm curious how the change event is ge
At 11:05 PM 7/12/00 +0100, Steve Alexander wrote:
ZPatterns 0.4.0a4
The file "version" reports it to be "ZPatterns-0-4-0a1". That gave me a
shock! I thought for a moment that I'd been working on an obsolete
edition :-)
Specialists.py, line 28, method getItem() needs a docstring.
Changes
At 02:30 PM 7/13/00 +0100, Steve Alexander wrote:
Steve Alexander wrote:
I want to combine Shane Hathaway's BTreeFolder product with ZPatterns to
create a "BTree folder w/ Customizer support".
snip!
Instead, why not make PlugInContainer a mix-in class, and have concrete
classes for
At 08:50 AM 7/13/00 +0100, Steve Alexander wrote:
"Phillip J. Eby" wrote:
Changes checked in. I should be releasing an alpha5 tomorrow.
That's great. Did you get my message about errors in triggered methods?
Yes, I did, but the solution requires some more thought. I had tho
At 07:11 PM 7/13/00 +0400, Ava wrote:
first generic attribute provider:
fromexpr = '(self.id[0] and sql_get_first(key=id[0]) or [NOT_FOUND])[0]'
attrsexprs = ['first_data=RESULT.data']
second generic attribute provider:
fromexpr = 'self.id[1] and sql_get_first(key=id[1]) or
Here's the details from the CHANGES file:
New Features/Bug Fixes in 0.4.0alpha5
- Property Sheets for DataSkin-based ZClasses. Now you can put define
property sheets on a ZClass and still use AttributeProviders for the
properties. Just add a "DataSkin Property Sheet" to your ZClass
At 05:41 PM 7/19/00 +0300, Itamar Shtull-Trauring wrote:
class ASPAccount(LoginUser, MemberMixin):
def __init__(self, id, title=''):
LoginUser.__init__(self, id)
self.__dict__['_currentPayment'] = None
self.__dict__['debt'] = Payment.Debt(0.0)
At 10:15 AM 7/19/00 -0400, Shane Hathaway wrote:
Chris Withers wrote:
"Phillip J. Eby" wrote:
Maybe, maybe not. I think perhaps the most compelling argument from
Digital Creations' viewpoint for having an expanded "access" file
might be
the simplification
At 11:09 AM 7/19/00 -0400, Shane Hathaway wrote:
Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck,
I've been tempted to do it as a LoginManager function, since Zope doesn't
pay attention to anything past the first line of the "access" file...
We would be most
At 12:50 PM 7/19/00 -0400, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
At 11:09 AM 7/19/00 -0400, Shane Hathaway wrote:
Patch opportunity, perhaps? :) Ty and I would do it, no problem.
Heck,
I've been tempted to do it as a LoginManager function, since Zope
doesn't
pay
At 01:27 PM 7/19/00 -0500, Phillip J. Eby wrote:
Hm. I don't think this could be classed as a "minor" change, however,
since it has impact on ownership, for example. What's the path of the user
folder which is above "/", for example? The whole thing is useless if
the
I've further enhanced yesterday's patch with the following additions:
* "Short-circuit evaluation" of local roles in User.getRolesInContext().
This speeds up security evaluation for complex DTML by stopping the local
role search as soon as one of the desired roles is found. The change is
fully
At 10:54 AM 7/25/00 -0400, Brian Lloyd wrote:
I think that this is _definitely_ the kind of thing that
should be done in the fishbowl on dev.zope.org. Why? Because
while it may be a "minor patch" in terms of lines of code, just
applying the patch causes a number of problems that have nothing
Question... Are you on 2.1.x or 2.2? Also, in your example, tpc_entered
is not set because tpc_entered is only true if the transaction commit
process (tpc = two-phase commit) has been started.
At 11:53 AM 7/27/00 +0400, Jephte CLAIN wrote:
Ok, so ZPatterns.Transactional._unregistered method
At 09:15 AM 7/27/00 +0100, Steve Alexander wrote:
Bill Anderson wrote:
Let's say I have an object I will store in a rack. Let us say I want
this object to be
cataloged in a ZCatalog. Any caveats I need to know about
..such as "Don't do that!" ?
?;^)=
Make one of the object's base-classes
At 07:12 PM 7/27/00 +0400, Jephte CLAIN wrote:
"Phillip J. Eby" a écrit :
Question... Are you on 2.1.x or 2.2?
I'm still on 2.1.6. I cannot afford a migration of my product now since
it is still in developpement and my customer wants it to work as soon as
possible.
Okay, that m
At 08:06 PM 7/27/00 +0400, Jephte CLAIN wrote:
By the way, besides new features like skinscript and proxy settings, did
you fix any bugs from 0.4.0a5 in 0.4.1a5 that would make me have to
upgrade my current ZPatterns?
IIRC, nothing that would affect you on 2.1.6. I vaguely recall some fixes
Despite the implications of the bait-and-switch subject line, I have not
yet written any substantial amounts of documentation. I have, however,
written this:
http://www.zope.org/Members/pje/Wikis/ZPatterns/DataSkinsOverview
DataSkins (formerly known as RackMountables) are central to the
At 10:58 PM 7/27/00 +0100, Steve Alexander wrote:
"Phillip J. Eby" wrote:
Just comment, please, preferably in e-mail via Zope-dev.
Thanks.
Generally very clear and helpful. Tomorrow, I'll try it out on someone
who hasn't been looking at ZPatterns a great deal, and see what she
Many people have suggested splitting out the PlugIns part of ZPatterns as a
seperate product for general Zope use. In addition to this, it is becoming
clearer to me as I work on docs, etc., that there really is only one thing
left in ZPatterns after you take out PlugIns, and that is DataSkins.
At 09:51 AM 7/28/00 +0100, Chris Withers wrote:
Steve Alexander wrote:
"Phillip J. Eby" wrote:
So, I am thinking perhaps I should split ZPatterns into two products:
PlugIns and DataSkins.
If 'PlugIns' includes plugins, plugin groups and plugin containers, then
that's a pretty
At 10:22 PM 7/28/00 +0100, Chris Withers wrote:
Steve Alexander wrote:
There are various types of DataManager in ZPatterns, and the important
ones take plug-ins so that you can greatly modify their behaviour.
I thought there were only two right now?
Technically, there are three - Specialist,
At 08:07 PM 7/30/00 +0100, Steve Alexander wrote:
Steve Alexander wrote:
I'm using ZPatterns 0.4.1snap1.
DataSkins.py line 377
method _v_currentSheets(self,_v_dm_=_v_dm_)
l.extend(list(sp._PropertySheetsFor(client)))
However, the variable "client" isn't declared elsewhere.
..and
At 11:09 PM 7/30/00 +0100, Steve Alexander wrote:
Let's say I have an AddressBook specialist.
Why? :)
Seriously, what is the function of "address book" in your application? Is
it to find people in general? Or...?
Let's say I want to combine my AddressBook with a Suppliers specialist.
The
At 07:09 PM 8/2/00 -0600, Bill Anderson wrote:
I think I have a decent handle on this concept, but something seems
lacking, I hope
someone can clear it up :)
So, let us say I have an object, call it a Member. :)
And let us say I want to be able to add a property sheet to it in a
At 05:38 PM 8/3/00 -0600, Bill Anderson wrote:
"Phillip J. Eby" wrote:
PersistentSheetProviders can do what you want - *but* there is one
drawback. PSP's have no concept of a sheet schema, so you have to add the
sheet and set up its schema in code for *each instance*.
Rats. :/
At 01:57 PM 8/8/00 +0200, RC Compaan wrote:
I've added a propertysheet called "properties" to my ZClass and i notice
there is Persistent Sheetprovider under the default rack already. The
Sheetprovider has properties Sheet_Names and Sheet_Namespaces. I guess
Sheet_Names should refer to the
At 06:07 PM 8/8/00 +0100, Steve Alexander wrote:
"Phillip J. Eby" wrote:
Actually, neither relates. Property sheets created on ZClasses always have
their data stored in attributes of the object itself, so if you want to
control those property sheets you would not use a sheet provi
At 05:23 PM 8/10/00 +0400, Jephte CLAIN wrote:
Hello,
I feel a need to invalidate a dataskin attribute cache after it has been
edited, because other objects might want to use the just modified
dataskin, but with the new values.
Of course, these values come from some attribute providers that
At 11:58 PM 8/9/00 +0100, Steve Alexander wrote:
1: ZClass instances can have PropertySheets added to them, independently
of any sheets declared in the ZClass class definition.
I've been working with Zope for a while, but this had never occurred to
me. I guess this is just another one of those
At 09:23 PM 8/24/00 +0100, Steve Alexander wrote:
I'm using ZPatterns 0.4.1snap1.
The LinkToParentProviders datamanager doesn't work properly because it
assumes that the Specialist it lives in has a _PropertySheetsFor(client)
method.
However, Specialists (and DataManagers) don't provide this
At 11:53 PM 8/20/00 +0200, Terje Malmedal wrote:
I've written this, but it just does not work, all that happens is that
it writes opened to /tmp/source.log
class USER:
"Just a little test"
name= None
roles = [ 'Anonymous' , 'member' ]
domains = []
def __init__(self,
At 04:32 PM 8/21/00 +0400, Jephte CLAIN wrote:
"Phillip J. Eby" wrote:
I don't see a need for a mass invalidation operation, just more
documentation on these inner workings. :)
or the lack of an attribute depencies mechanism :-)
if attribute x depends on attribute y from anoth
At 10:04 AM 8/22/00 -0500, Steve Spicklemire wrote:
Moving this to ZPatterns brings up all sorts of questions. First of all I
no longer
know that the actual class stored my shopper specialist is a 'Shopper'. It
could
be any class kept in the shopper manager's rack(s). Soo... my addShopper
Hi folks. I'm working on a ZPatterns 0.4.2b1 release for the early part of
the coming week, and intend to bug Ty into perhaps releasing an 0.9.0 beta
later in the week. However, these versions are likely to have some
(hopefully minor) compatibility issues with previous releases. Specifically:
At 10:22 AM 8/27/00 +0100, Steve Alexander wrote:
I've fixed this by adding a test to the start of __set_attr__ of
DataSkins.py:
def __set_attr__(self,name,val,_v_dm_=_v_dm_):
+ if name=='id' and val==self.__dict__['id']:
+ return
dm = self.__dict__[_v_dm_]
This
At 11:04 AM 8/27/00 +0100, Steve Alexander wrote:
I have been putting CatalogTriggers as DataManagers directly in
Specialists.
And this *works*??? None of the "Acquired ... Provider" classes supported
forwarding to an acquired trigger, as far as I can recall. The fact that
it's so bloody
At 07:32 PM 8/29/00 +0100, Steve Alexander wrote:
To reproduce the error, do this:
Create a Folder with Customizer support
Give it a Customizer
Rename that Customizer
Press the "Customizers" tab in the folder
Zope Error
Error Type: AttributeError
Error Value: __customizerRegistry__
At 04:13 PM 8/28/00 +0100, Steve Alexander wrote:
Zope 2.2.1, ZPatterns 0-4-1snap1, with some small patches.
I'm adding a dataskin-derived ZClass instance underneath a Customizer
folder.
The Customizer has a SkinScript plug-in.
When I try to add a new ZClass instance, I get an exception that I
Mostly bugfixes and internal reorganizations, some very minor feature
additions. This thing is finally beginning to stabilize a bit. Wish me
luck on getting some time to document SkinScript... :)
Meanwhile, my department is about to embark on a significant production
product using ZPatterns,
This is just a SWAG (Strategic Wild-Ass Guess), but Ty and I have been
having a problem with the search feature in Squishdot 0.7.0 that seems
possibly to be related. Our trace of the problem shows that catalog
searches from the SquishSite return objects which are wrapped with a
*different*
At 08:46 AM 9/5/00 -0500, Steve Spicklemire wrote:
OK I think I found the actual intent of aq_base() in _checkId of PlugIns.py:
...
it comes from the ObjectManager _checkId which has basically the same
code execpt it ObjectManager.py also has the needed:
from Acquisition import aq_base
Fixed
At 01:41 PM 9/14/00 +0100, Steve Alexander wrote:
I think there's something not quite right about the way ZPatterns is
handling subtransactions, even with this patch, and the other one
related to Transactions.py that I posted a while back.
Is there any detailed documentation about how Zope
At 03:56 PM 9/14/00 +0100, Steve Alexander wrote:
Can we lose DynPersist altogether for this release?
Unfortunately, no. Zope's cPersistent class appears it may have a bug that
is roughly similar to the one we're fixing in DynPersist. (i.e., not
calling __of__ or other binding operations on
inside other Specialists without getting an error.
At 03:56 PM 9/14/00 +0100, Steve Alexander wrote:
"Phillip J. Eby" wrote:
I will try to have a ZPatterns snapshot release made this week that will
include those fixes (plus the fix for a problem with DynPersist that we
also discovered
At 05:39 PM 9/14/00 +0100, Steve Alexander wrote:
Phillip J. Eby wrote:
It's up now. In addition to the transaction fixes and DynPersist fix, this
release also fixes the missing import of aq_base in PlugIns.py, and the
SkinScript compiler fouling up certain expressions due to its removal
At 09:18 PM 9/17/00 +0100, Steve Alexander wrote:
ZPatterns-0-4-2a2
When I use an External Attribute Provider, I get an infinite recursion
problem, and Zope hangs.
Argh. This is what happens when I create a new feature on the spur of the
moment and toss it in just before a release. :(
This
At 08:43 AM 9/22/00 -0400, Jim Fulton wrote:
Also, does anyone know of any work done to extend ZSQL Methods to allow
stored-procedure calls?
No, but I'd love to see someone tackle it. The semantics
of stored procedures varies so widely accross databases, that
I doubt that it would be easiliy
At 12:49 PM 9/22/00 -0400, Jim Fulton wrote:
"Phillip J. Eby" wrote:
Ty and I have put together a Stored Procedure method for Sybase; it
requires a minor patch to ZSybaseDA, however, to allow for the status code
return. I'm not sure how useful it would be to anyone else, though,
At 08:00 AM 9/25/00 -0500, Steve Spicklemire wrote:
So my retrieve item gets called. *unfortunately* it gets
called without any namespace parameter... so my retrieveItem
DTML method has no way to acquire a namespace so that it can
delagate to something else!
So... here is what I did... I
1 - 100 of 229 matches
Mail list logo