[ZPatterns] Revisiting an old question: Reusable ZPatterns applications

[Itai Tavor]

>Steve Spicklemire wrote:
>
>>Hmm.... what if the actual persistent storage were separated from 
>>the Rack? Steve.. didn't you cook up and External storage for Racks 
>>at some point? This way the stored objects could be 
>>exported/imported using the "normal" approach and the Rack (and 
>>it's PlugIns) could be updated separately.
>
>
>I did do this. I called it a "RemoteRack". Its internal BTree was 
>actually somewhere else in the ZODB, and was resolved by 
>unrestrictedTraverse, and cached in a _v_ attribute.

Now, this is interesting. If I got my factory code to create a copy 
of the app code, as well as set up a folder with RemoteRack instances 
for it, I would then be able to upgrade the whole app without 
touching the data... But some problems would still remain, because 
there might be other objects in the app instance that I don't want to 
override - such as UI skins or any methods that were added to 
customize a specific instance. So a selective update (probably with 
ZCVSFolder) would still be required, making it still much more 
complex than a simple upgrade of a classic Zope Product.


>I'd originally planned to have either the application or the rack's 
>data on a mounted ZODB filestorage. So, I'd have two filestorages; 
>one for the data and one for the application.
>
>The data and the ZCatalogs would live on the main Data.fs storage, 
>so that you could undo changes to data as normal.

This reminds me of another problem I wanted to post about. The 
separation of problem domain code from data management in ZPatterns 
means, I think, that you should not rely on specific features of a 
specific storage method in the application. If you rely on the Undo 
capability of ZODB-based Racks, the PD-DM separation is gone.

>On updating your application you'd still probably want to repopulate 
>ZCatalogs based on the ids of the persistent items in the rack.

Why would this be necessary? If the Catalogs live in the non-updated 
part, and the data ids and physical paths do not change, wouldn't the 
Catalogs remain up-to-date?


>I'm not using RemoteRack at the moment. I don't have the code to 
>hand just now, and it would certainly need updating for the latest 
>ZPatterns -- although the changes would be minor.
>
>It wouldn't take much to rewrite such a thing either.

Shame... would be nice to have working code available. But anyway, 
it's it's an interesting solution to keep in mind.
-- 
--
Itai Tavor                      -- "Je sautille, donc je suis."    --
itai@optusnet.com.au            --               - Kermit the Frog --
--                                                                 --
-- "If you haven't got your health, you haven't got anything"      --