[Zope-dev] advice on MountedFileStorage changes.
I've nearly completed the code to make MountedFileStorage able to create new FileStorages on demand, _however_... I'm hitting a bit of a problem with the Product initialisation. Right now I'm just calling OFS.Application.initialize(), which goes through and re-imports all the products, and adds them to the global meta_types list. This is bad - it means it's slow as hell reimporting everything, and everything gets listed twice. It's fine after a restart, but that's not much help. I can't just skip product initialisation, as it's kinda needed to create objects in the sub-zodb. So, approaches I'm considering: passing a flag through initialize() saying 'don't put products in the meta_types' (seems hacky). subclassing OFS.Application.Application, and copying the method except for the last line that alters the meta_types (fragile - have to track changes to the main body of code). trying something else entirely, such as copying the products from the main products folder, and installing them that way... ? Any ideas appreciated. (There's an ongoing issue, too - there will need to be some sort of way to copy any new/changed Products from the main ZODB to the children...) Anthony ___ 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] 0.4.0 prerelease snapshot (was zpatterns-0.4 ?)
By popular demand, I am releasing a development snapshot of version 0.4.0.
Please see the main ZPatterns download page.
This is EXTREMELY ALPHA and includes a fair amount of code that just got
written or debugged today. Actually, most of the stuff I wrote today got
exercised pretty well. I'm more concerned about whether I broke anything
that worked before in the process, as I haven't come up a way to regression
test this thing except manually. :(
Anyway... there are quite a few undone bits as yet, but the main things
are there. DataSkins, and Folders w/Customizer support, for example. Ty's
ExprGetter AttributeProvider, which is pretty cool, and my updates to it to
make it even cooler. :)
Some things that may not work right... DataSkins need to have their
_objectAdding()/_objectDeleting() methods called from
manage_afterAdd/manage_beforeDelete, and if you subclass ObjectManager or
CatalogAware or anything else with custom hooks for these methods, you may
break add/delete events, which are required for some things to work. This
might not affect you in the prerelease, because not much is wired to the
events yet. But they may break in the final release.
In general, you should assume that this release is dangerous. On various
occasions today, it has caused Zope to dump core. In each case, I found
and fixed the problems, which had to do with the new deep
acquisitional/transactional/computedattribute magic for DataSkins. There
is no guarantee, however, that I have fixed all such bugs.
I reserve the right to make incompatible changes between this release and
the final 0.4.0, that would require you to delete all prerelease-based
objects and start over. (I am doing my best to maintain transparent
upgradability from 0.3.0, however. But I won't be putting in data upgrade
code for interim releases.)
Last, but not least, the docs are even worse than usual for my releases,
and some of the newer objects have ugly, missing, or confusing interim
icons. So all in all, use at your own risk.
At 04:06 PM 6/7/00 +0300, Itamar Shtull-Trauring wrote:
>"Phillip J. Eby" wrote:
>
>> I'm shooting for release by the end of next week. Search plugins have not
>> been finished yet, but in any case they will NOT work with prior versions;
>> there is no place to plug them in, nor will any of the old code call
them. :)
>
>Could you maybe release a preliminary version in the beginnng of the week,
>even if it's not finished? I'd like to start designing a Product using the
>events-sending interfaces, and it'd be a real help if I could know even
>approximately what the interfaces looked like. Not that I'm rushing you or
>anything :)
Have a look at Agents.py in the new release. To have an object that
receives events, subclass the Agent class, and override:
def _getMementoFor(self,client):
def _objectChanged(self,client,memento):
def _objectDeleted(self,client,memento):
def _objectAdded(self,client):
as appropriate. getMemento should return a snapshot of any data you want
passed into the methods that take a "memento" parameter. Make sure your
memento contains only "immutables all the way down", since the object
you're watching ("client")might change anything that's mutable.
By the way, the final release of 0.4.0 should (time permitting) include an
"ExprNotifier" which can automatically translate the above events into
calls to arbitrary DTML expressions, including handling memento generation
for you by saving specified expressions executed against the object before
it changes.
___
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] Externalize or Adapt? (ZPatterns)
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 different specialists; just drop in more than one. I suppose you could even make the DelegationRack have an expression to use to translate from the ID asked for in the horizontal specialist, to the kind of ID used by the vertical specialist, perhaps by using a search function of the vertical specialist. >I'm just considering on specialized racks which >implement non-standard api, such as 'findItem( criteria)', >'itemValues()' or something similar. > >By the way, racks should have a kind of 'scanning' api, like Zope's >Folders, at least they should have itemIds() method. This is waiting for indexes and predicates; which won't hit until 0.5.0. Meanwhile, I'll add a getPersistentItemIDs() method to Rack in 0.4.0. This will not get you the id of all possible items in the rack, since you might be using SQL or some other kind of storage. It will only get the items which have data or propertysheets in the ZODB. Currently, the correct way to have 'scanning' API's is to implement them on your Methods tab using SQL methods, LDAP methods, or whatever is appropriate for your dataset. In 0.5.0 or later, hopefully there'll be some sort of plug-in API for that. ___ 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] Externalize or Adapt? (ZPatterns)
Mike wrote: > > > I will add a "retrieveItem" method to the Specialist which, instead of > > accessing a rack in the local specialist (the default implementation), it > > will instead call (for example) SkyDivers.getItem(). Thus, when you call > > Customers.getItem(), you will actually get an object from the SkyDivers > > specialist. In other words, I make the horizontal domain specialist > > delegate to the vertical specialist. 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. I'm just considering on specialized racks which implement non-standard api, such as 'findItem( criteria)', 'itemValues()' or something similar. By the way, racks should have a kind of 'scanning' api, like Zope's Folders, at least they should have itemIds() method. Mike ___ 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] Externalize or Adapt? (ZPatterns)
> I will add a "retrieveItem" method to the Specialist which, instead of > accessing a rack in the local specialist (the default implementation), it > will instead call (for example) SkyDivers.getItem(). Thus, when you call > Customers.getItem(), you will actually get an object from the SkyDivers > specialist. In other words, I make the horizontal domain specialist > delegate to the vertical specialist. Got it! Thanks. Now I see my previous questions was like 'where to put horse in steam engine' ;-) ___ 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 )
