Re: [Zope-dev] SAP DB -- ZODB ?
On Friday 09 March 2001 07:20, Steve Alexander wrote: I just heard that the SAP DB has gone Free and Open Source. sapdb isn't open source yet. it will be in a few months. when it does it looks like it will instantly become the most advanced open source database out there. my current rankings of the general os rdbms in terms of features postgresql-interbase-mysql currently sapdb has only opened the database manager and the client interfaces as well as the build environment needed to make these from src. the feature list of this database is astonishing www.sapdb.org to name a few subtransactions outer joins sql 92 compliant, possible modes for db2, oracle 7 very nice prodecural sql language. lots of statistics information really rich set of standard functions scrollable cursors this is a great candidate for a zodb storage kapil 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 ___ 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 ) ___ 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] SAP DB -- ZODB ?
ender wrote: On Friday 09 March 2001 07:20, Steve Alexander wrote: I just heard that the SAP DB has gone Free and Open Source. sapdb isn't open source yet. it will be in a few months. It is GPL-ed now, and you can download it now. http://freshmeat.net/projects/sapdb/ -- Steve Alexander Software Engineer Cat-Box limited ___ 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 )
[Zope-dev] Designing ZPatterns/Python-product-based, reusable applications -take 2
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 ,
[Zope-dev] State of ZPatterns
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."-- [EMAIL PROTECTED]-- - Kermit the Frog -- -- -- -- "If you haven't got your health, you haven't got anything" -- ___ 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] State of ZPatterns
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. :) 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.) 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. 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. 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. ___ 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] Designing ZPatterns/Python-product-based, reusable applications - take 2
At 10:24 AM 3/11/01 +1100, Itai Tavor wrote: 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. Or you may want to just create one factory method that creates an entire family of related Specialists. Specialists do support TTW overriding of their methods, if you set up the methods properly in your Python code. (I forget how this works, though, you'll probably need to check the source code.) - 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? Yes. Use "class_default_for_X" methods. (e.g. "def class_default_for_index_html"). This will make them capable of being overridden with a Class Extender in the Rack or Specialist. 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). Your factory code can set this up, although I admit it's ugly. 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? Placing them in a folder would be fine. Actually, it would suffice simply to install a meta type which creates all the Specialists in the selected folder. Note that Zope does not require that a meta type correspond to some physical class, or that an add operation result in a single object being added to a container; you can add as many objects as you want in the same operation. 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? If I understand you correctly, then you'd just instantiate another instance of the application metatype, and then customize whatever needed to be customized. 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... If your factory methods set this stuff up, then you're okay. 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. IMHO, ZPatterns is actually pretty mature - in terms of its code. By that I mean, it has gone about as far in capabilities as its internal architecture will allow. There are many minor improvements that could be made, but they would be costly compared to their benefit. I would rather invest the effort in something that will produce a greater gain for me and the rest of the community. TransWarp will be much better for filesystem-based, Python products than ZPatterns, which is almost 100% through-the-web focused. The key phrase, though, is
