- Zope-Dev - Zope lists

Re: [Zope-dev] State of ZPatterns
by Itai Tavor 11 Mar '01

11 Mar '01

Phillip J. Eby wrote: >At 10:16 AM 3/11/01 +1100, Itai Tavor wrote: >> >>I'm wondering where TransWarp leaves ZPatterns users. Until a couple >>of weeks ago ZPatterns was the best thing to happen in the Zope world >>since, well, Zope. Now it's described as a 'hack', > >Those things aren't mutually exclusive, you know. :) I realize that... I just got the impression that your own view of the value of ZPatterns suddenly took a nose dive. Guess I was wrong, and I'm happy to know that. > >demoted into >>'maintenance only' mode, and superceded by something that is >>described as being as much better than ZPatterns as ZPatterns was >>better than standard Zope development. > >It hasn't been superceded. TransWarp has several layers of functionality >planned; only one of those layers has been released to date. (By the way, >I also don't recall ever saying even that TransWarp was "better" than >ZPatterns, let alone that it was some giant leap forward. I did say that >it expanded further on the model which was the basis for ZPatterns, however.) Sorry for putting words in your mouth. My understanding was, though, that TransWarp will replace ZPatterns as the best tool for object model based development, which means that the idea of developing ZPatterns code with a view for long term future reuse suddenly isn't that attractive. > >As for "maintenance only", ZPatterns hasn't had any changes in months, >except for patches provided by its users. That's largely because it hasn't >needed any. There's not much you can *add* to ZPatterns, without a major >upheaval. I figure, let the major upheaval be directed at making something >completely different, rather than have major reworking to make something >only marginally better. I fully agree. I just didn't expect something with a 0.4.3b2 version number to remain unchanged. Also, I remember you mentioning that you're working on an SQL DataSkin. If that was really a possibility in the past, and it won't happen, then it's a major loss. Documentation/examples is another area that still needs to be improved (although the community can be considered to be responsible for that as much as yourself). > >So what do we do now? Wrap up current ZPatterns work, writing it off >>as a loss for future reuse? Or can we count on 'maintenance only' >>being sufficient to support continued reused of ZPatterns efforts >>long enough to justify the original development effort? > >Someone asked a similar question of me at the conference. I told them that >if I needed to develop a web-based application today, I would use ZPatterns >with Zope. It works, it's stable, it gets the job done. If you use it for production sites, that's good enough for me :-) > >Also, recall that the RIPP model concept was introduced to the Zope >community last January, and it was many months before ZPatterns' first >release, then many more before it was stable enough to be ready for >production use. Expect the same to be true of TransWarp. The tools >released so far are rock solid, but there isn't anywhere near enough there >to compete with ZPatterns yet. This is ok as long as you're choosing a tool per project. But I'm hate repeating work, and I expect the ZPatterns-based e-commerce app I'm building today to make the e-commerce app I build in 12 months a lot easier to build. So any changes in the basic tools I use bother me. Anyway, you did well calming my concerns. Thanks for that, and for releasing ZPatterns in the first place. -- -- Itai Tavor -- "Je sautille, donc je suis." -- itai(a)optusnet.com.au -- - Kermit the Frog -- -- -- -- "If you haven't got your health, you haven't got anything" --

1 0

ZPatterns: External Attribute Provider question
by Steve Alexander 11 Mar '01

11 Mar '01

Hi Phillip, Is there a good reason that ExternalAttributeProvider sets up a dictionary to put its attributes into, rather than a PersistentMapping? This is the way it seems to store things in the Rack: Rack's BTree | + object_id : PersistentMapping | + ('ZPatterns.Rack', 'Self') : Persistent object, eg ZClass instance + ('ZPatterns.AttributeProviders','ExternalAttributes') : {} # dict filled with external attributes The thing is that when the dict gets updated by the External Attribute Provider, the whole second-level-in PersistentMapping object gets updated. If an External Attribute Provider instead set up a new PersistentMapping in its slot, only that PersistentMapping would change in the ZODB on updates. Do you think this is a reasonable change for the External Attribute Provider class? Or, should I write my own provider, derived from External Attribute Provider, that uses a PersistentMapping instead of a dict? Actually, I can see the use for a Persistent AttributeProvider where you have a configurable slot, so you can group attributes that change at different rates in groups of those that change together. The second half of the slot-key's tuple would be configurable as a property on the attribute provider. -- Steve Alexander Software Engineer Cat-Box limited

2 1

FYI: TransWarp talk slides posted
by Phillip J. Eby 11 Mar '01

11 Mar '01

HTML Version (frames & JavaScript required): http://telecommunity.com/TransWarp/IPC9Talk.htm PowerPoint Version: http://telecommunity.com/TransWarp/IPC9Talk.ppt

1 0

Designing ZPatterns/Python-product-based, reusable applications - take 2
by Itai Tavor 11 Mar '01

11 Mar '01

Hi, I didn't get very far asking this question a little while ago, so I'm going to try again. I started developing ZPatterns applications in the ZODB. Then I figured there would be advantages to moving instead to python product-based development. My goal is to create applications that can be reused easily, but I'm having problems deciding on the best way to structure the application, how the requirement of reusability affects the structure, and how reuse will actually take place. The starting point is an object-model based application, so unlike applications like zCommerce and EMarket, where you start from an API, template, or skeleton and build on that, I'll be trying to reuse parts of an actual, complete, live application. Starting with PD classes: Those would be DataSkin-subclassed python classes. Reuse would involve either using these classes as-is, or subclassing them where changes are needed. No problem here. Then I need Specialists to manage collections of PD classes. I think that these would also benefit from being product-based, so I subclass Specialist to create a manager for each role in the application. Now, since an existing application might be expanded, the Specialists all need factory methods and will all show up in Zope's Add New Object menu. Now consider UI: - Both PD and manager classes will have administrator UI. This would not have to change unless the class is subclassed, so the UI methods can stay in the product and loaded using HTMLFile. - Many of the classes will also have web user UI, and since this has to be designed to fit the design of the web site in which the application is used, the UI methods will have to be located where designers can modify them - in the ZODB. For the Specialists, I can install a default set of UI methods when an instance of the Specialist is installed. But where do I store PD class UI methods? EMarket's solution is to store them in the Specialist, but this not only breaks O-O rules, it can also be very ugly. Say I have a Specialist managing 3 PD classes. Instead of an index_html method for each class, I'll need class1index_html, class2index_html, class3index_html in the Specialist. And each class would have to define: def index_html(self, REQUEST, RESPONSE, **kw): return self.class1index_html(REQUEST, RESPONSE, kw) This is unacceptably ugly. But the only other thing I can think of doing is creating a ZClass for each PD class and store the UI methods there. But that's also pretty unacceptable. Is there a better solution? Next, I need object connections - these are created using SkinScripts. And as far as I can tell, I can't manage SkinScript in the product - they have to be in the ZODB. Which is ok in O-O land as they're not strictly part of the PD classes, but this means that PD classes don't actually work at all until someone comes and fills in the SkinScripts - so the class actually misses a lot of the code it requires to function. Also, it means SkinScript code can't be reused with the rest of the application's components (except by cutting and pasting code pieces from an existing application). I also need storage management - which is done with Rack methods and SkinScripts in the Racks. The SkinScripts present the same problem as the ones used for object connections. Rack methods can be ZODB-based, in which case again they can't be easily reused and need to be manually created before the objects start doing anything, or they can be created in Rack-subclassed classes, but that creates a problem for RDBM storage - unless it's possible to store SQL methods in a python product. Finally, I need to wrap the whole thing up as an application. So I create a Folderish class which installs instances of all Specialists, and add application-wide utility methods. Or do I simply place all Specialists in a Folder? Now, about reuse. O-O reuse, as far as I understand it, takes place at the class level. So how do I start a new application? Do I subclass its main container class and and my own init method that adds any added or subclassed Specialists I use? Or do I create my own application class and import PD classes from the old application? Do I copy the old classes into my new product, or do I import them from the old product, which then would require that the old product is kept on the server, even if the application that product defines isn't used on this server? And, as mentioned above, how do I reuse SkinScripts, Rack methods and SQL methods? Copy and paste? It seems funny that if I create a new instance of the product, I don't get a new copy of a working application... That's it. Sorry it's so long and complex. What would be great is if someone posted a description of the structure of a working application. I'm sure this is something many people are likely to struggle with - it almost could be a HowTo. I hope, now everyone are back from the conference , that I'd have more luck getting some help :-) On the other hand, considering that ZPatterns is now being superceded before it even had a chance to mature, maybe nobody cares to hear about it anymore :-( But more on that in a separate post. TIA Itai -- -- Itai Tavor -- "Je sautille, donc je suis." -- itai(a)optusnet.com.au -- - Kermit the Frog -- -- -- -- "If you haven't got your health, you haven't got anything" --

2 1

State of ZPatterns
by Itai Tavor 11 Mar '01

11 Mar '01

Hi, I'm wondering where TransWarp leaves ZPatterns users. Until a couple of weeks ago ZPatterns was the best thing to happen in the Zope world since, well, Zope. Now it's described as a 'hack', demoted into 'maintenance only' mode, and superceded by something that is described as being as much better than ZPatterns as ZPatterns was better than standard Zope development. So what do we do now? Wrap up current ZPatterns work, writing it off as a loss for future reuse? Or can we count on 'maintenance only' being sufficient to support continued reused of ZPatterns efforts long enough to justify the original development effort? Do any other ZPatterns users share these concerns? Itai -- -- Itai Tavor -- "Je sautille, donc je suis." -- itai(a)optusnet.com.au -- - Kermit the Frog -- -- -- -- "If you haven't got your health, you haven't got anything" --

2 1

SAP DB <--> ZODB ?
by Steve Alexander 10 Mar '01

10 Mar '01

I just heard that the SAP DB has gone Free and Open Source. ---- SAP DB is an open, SQL-based, relational database management system that provides high availability and performance scaling from small to very large implementations. In addition, SAP DB goes beyond relational database technology by offering object orientation as well as support for managing unstructured data. It supports open standards including SQL, JDBC and ODBC; access from Perl and Python; and HTTP-based services with HTML or XML content. SAP DB is platform independent, so users can deploy it for a wide array of projects. Since 1994, the SAP e-Business Solution is available on SAP DB technology. Today SAP DB is being used by nearly 800 customers. On October 5, 2000, at Linux World SAP DB was announced to be made available as Open Source software using the GNU General Public License for the database kernel and the GNU Lesser General Public License for clients and programming interfaces. ---- http://freshmeat.net/projects/sapdb/ I'd never heard of SAP DB before, although I've heard of SAP. This looks as if it would be good for a ZODB storage. -- Steve Alexander Software Engineer Cat-Box limited

3 3

SECURITY ALERT and Zope hotfix release [2001-03-08]
by Brian Lloyd 09 Mar '01

09 Mar '01

Hello all - An issue has come to our attention (thanks to Randy Kern) that necessitates a Zope hotfix. Hotfix products can be installed to incorporate modifications to Zope at runtime without requiring an immediate installation upgrade. Hotfix products are installed just as you would install any other Zope product. This hotfix (Hotfix_2001-03-08)addresses an important security issue that affects Zope version 2.3.0 and the current 2.3.1 beta 1 release. The issue involves an error in the 'aq_inContextOf' method of objects that support acquisition. A recent change to the access validation machinery made this bug begin to affect security restrictions. The bug, with the change to validation, made it possible to access Zope objects via acquisition that a user would not otherwise have access to. This issue could allow users with enough internal knowledge of Zope to perform actions higher in the object hierarchy than they should be able to. We *highly* recommend that any Zope site running Zope 2.3.0 final or any alpha or beta version of 2.3.0 or 2.3.1 beta 1 have this hotfix product installed to mitigate the issue. Zope 2.3.1 beta 2 will contain a fix for the issue, at which time the hotfix can be removed. Zope versions prior to 2.3.0 are not affected by this issue. - http://www.zope.org/Products/Zope/Hotfix_2001-03-08/README.txt - http://www.zope.org/Products/Zope/Hotfix_2001-03-08/Hotfix_2001-03-08.tgz Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

Zope/Win2K/Crash ...
by Bryan Baszczewski 09 Mar '01

09 Mar '01

Anyone else using Zope on Win2K? We have recently installed Zope as a production server on Win2K (SP4) and everything was fine for the first couple of weeks. We started a little monitoring program which hits Zope every 5 seconds, and noticed Zope started to crash intermitently. In the NT Event Log I find: "The description for Event ID ( 3 ) in Source ( PythonService ) could not be found. It contains the following insertion string(s): <Error getting traceback - traceback.print_tb() failed, pywintypes.api_error, (1450, 'CreateProcess', 'No error message is available')." What is this telling me? That I ran out of memory? Bryan Baszczewski Software Engineer/Technology Strategist 2s2i, Inc. www.2s2i.com phone: (703)534-9800 x-203 fax: (703)995-4866 "Because word of mouth has gone global, there's e-Intelligence from 2s2i."

1 0

Re: [Zope-dev] Saving attributes for a DataSkin
by Johan Carlsson 09 Mar '01

09 Mar '01

> > Hi Johan, > > Could you give a more complete traceback? It's hard to tell > from just the error type.. > > thanks! > -steve Of course, here it comes. Regards, Johan Traceback (innermost last): File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ProviderContainer) File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: changeUser) File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: changeUser) File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/Shared/DC/Scripts/Bindings.py, line 324, in __call__ (Object: changeUser) File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/Shared/DC/Scripts/Bindings.py, line 353, in _bindAndExec (Object: changeUser) File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/Products/PythonScripts/PythonScript.py, line 330, in _exec (Object: changeUser) (Info: ({'script': <PythonScript instance at 8a1ffc8>, 'context': <LoginManager instance at 89d56e8>, 'container': <LoginManager instance at 89d56e8>, 'self': <TemplateDict object at 8a1e948>, 'traverse_subpath': []}, ('a', 'a', 'a', 'a', 'a'), {}, None)) File Script (Python), line 3, in changeUser File /bigshare/zopeservers/Zope-2.3.0-src/lib/python/Products/PythonScripts/zbytecodehacks/VSExec.py, line 429, in __setattr__ TypeError: (see above) > >>>>> "JC" == Johan Carlsson <johanc(a)torped.se> writes: > > JC> Hi, I'm having some trouble figuring out how to write a method > JC> and a skinscript to save attributes of a DataSkin. > > JC> Specialist is the LoginManager. > > JC> DataSkin is: > > JC> class EasyGroupUser(LoginUser): ... def getRoles(self): ... > JC> def getDomains(self): ... def authenticate(self, password, > JC> request): ... > > JC> SkinScripts are: WITH QUERY sql_getUserFor(username=self.id) > JC> COMPUTE username, password, challenge_question, > JC> challenge_answer, admin_email > > JC> WHEN OBJECT CHANGED STORE password, challenge_question, > JC> challenge_answer, admin_email USING sql_changeUser( > JC> username=self.id, newpassword=password, > JC> challenge_question=challenge_question, > JC> challenge_answer=challenge_answer, admin_email=admin_email, > JC> oldpassword=OLD['oldpassword'] ) SAVING oldpassword = password > > JC> Current Attribute Handling: admin_email Getters: SkinScript, > JC> line 1 Setters: SkinScript, line 10 Deleters: SkinScript, line > JC> 10 challenge_answer Getters: SkinScript, line 1 Setters: > JC> SkinScript, line 10 Deleters: SkinScript, line 10 > JC> challenge_question Getters: SkinScript, line 1 Setters: > JC> SkinScript, line 10 Deleters: SkinScript, line 10 password > JC> Getters: SkinScript, line 1 Setters: SkinScript, line 10 > JC> Deleters: SkinScript, line 10 > > > JC> The getter works alright, but when trying to set attributes > JC> (that supposedly would be handle by the setter) with the > JC> following Script (Python) I get the following error: > > JC> ## Script (Python) "changeUser" ##bind container=container > JC> ##bind context=context ##bind namespace=self ##bind > JC> script=script ##bind subpath=traverse_subpath > JC> ##parameters=username,password,challenge_question,challenge_answer,admin_email > JC> ##title= ## user = context.getItem(username) > JC> user.password=password > JC> user.challenge_question=challenge_question > JC> user.challenge_answer=challenge_answer > JC> user.admin_email=admin_email > > JC> ERROR MESSAGE: Error Type: TypeError Error Value: > JC> attribute-less object (assign or del) > > JC> So what am I doing wrong here? Any clues appreciated. > JC> TIA/Johan Carlsson > > > > JC> _______________________________________________ Zope-Dev > JC> maillist - Zope-Dev(a)zope.org > JC> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross > JC> posts or HTML encoding! ** (Related lists - > JC> http://lists.zope.org/mailman/listinfo/zope-announce > JC> http://lists.zope.org/mailman/listinfo/zope ) >

1 0

Re: [Zope-dev] TransWarp preview release (AOP tools only)
by Shane Hathaway 09 Mar '01

09 Mar '01

"Phillip J. Eby" wrote: > > At 12:39 PM 3/2/01 -0500, Shane Hathaway wrote: > >This could be achieved by generating a new Python module for each portal > >instance, but that would mean sys.modules would have to be pre-loaded > >with the information about each portal instance and that's not the ZODB > >way. It would be better to create a new class loader that can weave a > >new class on the fly based on persisted component metadata. Note that > >class loading is currently quite simple; see > >lib/python/Zope/ClassLoader.py (sp?). It could bear some complexity. > >:-) > > There's actually a simpler way. Aspect objects can be pickled as long as > all the objects in them can be pickled. Which means that as long as all > their methods are Zope objects, and all the nested classes are also Aspect > objects, you can save an aspect into the ZODB, and load it at a future > time. Further, since adding aspects together makes new aspects, you can > save the combined aspects, so you only have to perform one call to > transform the aspect into a family of classes. That still means some > load-time complexity, however. Perhaps... but as I see it, pickling the aspect weaving information into each object makes it harder to vary the aspect weaving after objects have been created. I would want to be able to create a portal, add some content, then change the aspects that apply to the content after it has been created. That means that either the objects have a class definition that references a centralized component or all content objects have to be re-woven every time you change the centralized component. I'm also planning outside the ZODB. The goal is to design apps using pure and simple ZODB and not be required to do anything special to make it work later with other forms of storage. Other databases will not be able to store aspect information. > It would be interesting if you could take an arbitrary Zope service object > (like a portal), and go to its "Aspects" tab, and add or remove aspects to > be woven with its class family. But I suspect it will be a long time > before I'll have a need for that personally or professionally, as I am > focused primarily on TransWarp as a CASE tool and Python application > toolkit at present. That's actually the kind of functionality we have now, but we're using subobjects rather than tabs and we achieve many of the things AOP would give us through simple delegation. You should check out the CMF as soon as the beta is released. Shane

2 2