Zope-Dev June 2000

zope-dev@zope.dev

119 participants
260 discussions

Merhabalar;
by Can Canbilek 13 Dec '01

13 Dec '01

Öncelikle rahatsýz ediyorsak özür dileriz ama bu maili okursanýz sanýrým bize teþekkür edeceksiniz. Sizlere, hiçbir masraf yapmadan yalnýzca internete girerek para kazanacaðýnýzý iddia ediyoruz. Hiçbir yalan dolan, hile olmadan.... Üstelik kredi kartý numaranýzý bile vermeniz gerekmiyor. Ufak bir formu dolduruyorsunuz, dünyaca ünlü bir þirket olan ve dünyanýn heryerine ( Türkiye dahil olmak üzere ) para yollayan bu þirketin küçük bir programýný download ediyorsunuz. Daha sonra her internete giriþinizde bu programý açýyorsunuz ve program nete ne kadar girdiðinizi hesaplýyor. Nete girdiðiniz her saat baþý 50 cent alýyorsunuz ve bunu karþýlýðýnda ekranýnýzýn küçük bi bölümünde reklamlar görünüyor... Ayda yalnýzca 60 saat internete girerek 30$ kazanýyorsunuz tabii daha fazla kazanmak isterseniz arkadaþlarýnýzý üye ediyorsunuz. Ýster saadet zinciri, isterseniz zeka kullanýmý deyin, bence bundan daha iyi bir yöntem yok.... Ayrýntýlý bilgi gelen çeklerimizin resimleri ve olasý sorularýnýzýn cevaplarý için aþagýdaki sitelerden herhangi birine giriniz(hepsi aynýdýr): http://www25.brinkster.com/firsatlar/index.htm http://www25.brinkster.com/hizmetlerimiz/index.htm http://www25.brinkster.com/spediainc/index.htm http://www25.brinkster.com/sendekazan/index.htm Saygýlarýmla... !!!!!!!SORULARINIZ ÝÇÝN LUTFEN cancanbilek2(a)hotmail.com ADRESÝNE MAÝL ATINIZ, BU MAÝLE REPLY YAPMAYINIZ!!!! ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- BU MAILI YANLISLIKLA ALDIGINIZA INANIYORSANIZ, YADA BIRDAHA BIZDEN MAIL ALMAK ISTEMIYORSANIZ http://www21.brinkster.com/dogangoko/index.htm ADRESÝNE GÝRÝN VE SAYFADAKÝ MAÝLLÝSTÝMÝZDEN ÇIKMAK ÝÇÝN BURAYA EMAÝLÝNIZÝ YAZINIZ BOLUMUNE EMAÝLÝNIZI YAZINIZ... ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- EGER BU MAILI 2CÝ KEZ ALIYORSANIZ LÜTFEN DÝKKATE ALMAYINIZ.... ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

4 3

Resize a image stored in a Oracle's BLOB Field
by Juan Javier Carrera Obrero 27 Nov '01

27 Nov '01

Hello, Thanks, I have displayed the images which them was stored in a Oracle's BLOB field, with: <dtml-call expr="RESPONSE.setHeader('content-type','image/jpeg')"> <dtml-in SQLMethod_with_a_Only_Row> <dtml-var expr="BLOB_FIELD.read()"> </dtml-in> However, I would like to resize this image. I can not do it with the "height" and "width" attributes, because the image is obtained from a Oracle's BLOB field, and no from image object (i.e.: I can not use <dtml-var "ImageObject.tag(border='5', align='left')">). How can I do it ? Thanks again !

4 3

Re: [Zope-dev] Acquisition wishlist :-)
by Dieter Maurer 09 Jan '01

09 Jan '01

Chris Withers writes: > And I suppose the other part of my wishlist: > > class MyClass(Acquisition.Implicit): > # your_attribute will be acquied > > # index_html won't > index_html = None No, that is not enough! As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts). Dieter

3 8

ZPatterns: DropZone example
by Steve Alexander 20 Sep '00

20 Sep '00

Hi folks, I've been looking at the DropZone example Phillip Eby provided on the ZPatterns Wiki. http://www.zope.org/Members/pje/Wikis/ZPatterns/DropZoneExample I've decided to start implementing it, so as to give myself an educational experience in using ZPatterns. I have an open question: 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 one Black-box specialist to do the "heavy lifting. Let's call it the "AccountingProcessor" specialist. Now, if I had a third-party accounts package (something by Sage perhaps), I could make the AccountingProcessor specialist expose various functions to the four other White-box specialists. It would implement these by making equivalent calls on the underlying accounting package. I could also swap the heavy-lifting portion of my framework by swapping the black-box AccountingProcessor specialist for one that talks to some software by Quicken, or perhaps some software that is written in Python as a conventional Zope product. The same goes for the Resource Scheduling framework. We have some White-box specialists, ripe for customisation: Resources Reservations ResourceUsers And then for the heavy-lifting we have the black-box ResourceScheduler specialist. Again, this might be a Zope Python Product, or it might be an interface to some application written on top of Microsoft Exchange. Are specialists intended to be placed inside other specialists, as "contents"? So in this case, would the white-box specialists live inside the black-box specialist -- so they become the customisable aspects of the overall framework? Or would both black-box and white-box specialists live inside an uber-specialist? Or is this just down to taste? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net

6 12

zpatterns-0.4a4
by Jephte CLAIN 16 Aug '00

16 Aug '00

There is a bug (a feature?) in Specialist.getItem in zpatterns-0.4a4: 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) return item 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) if item is not None: return item return None regards, jephte clain jclain(a)univ-reunion.fr

5 8

One more bug
by mike 19 Jul '00

19 Jul '00

Fix for www/storageForm.dtml $ diff storageForm.dtml.orig storageForm.dtml 7c7 < <FORM METHOD="POST" ACTION="manage_setStorage"> --- > <FORM METHOD="POST" ACTION="."> 56c56 < <br><INPUT TYPE="SUBMIT" value=" Change Storage Settings"> --- > <br><INPUT TYPE="SUBMIT" name="manage_setStorage:method" value=" Change Storage Settings">

3 3

Racks and Specialists Simplified
by Shane Hathaway 18 Jul '00

18 Jul '00

Phillip, I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also. I like to think of a specialist as a filing clerk. A manager comes to the clerk asking for an employee's dental records. Because of the way the company filing system was set up, however, the dental records aren't kept on a single slip of paper. The clerk has to compile the information from the employee's medical and insurance information. The manager doesn't care where the information is coming from, but needs the information on a standard dental record form. So the clerk compiles it and gives the manager the information on the correct form. In this example, the manager is the "application framework", the file cabinets are "racks", and once again the clerk is the "specialist". An application framework generally looks in database tables for objects of a specific type. The types of objects may include users, invoices, grades, etc. A rack is an abstract database table. The data can be stored in ZODB or in some other way, but the point is that a rack is a container for a list of objects of the same type. The basic functionality of a rack can be duplicated by creating a folder and populating it with methods that access a database table, then calling the methods of that folder rather than accessing the database directly. A specialist essentially provides views, or "sheets", of data from one or more racks. The information on a sheet is compiled from one or more sources and contains the precise information required of the application framework. If used correctly, the RIPP model makes integration of multiple Zope-based application frameworks relatively straightforward. This means that, for example, a Zope calendar product could gather date information from a Zope logging product, which of course knows nothing about calendars. Now, the above is what ZPatterns has been claiming all along. But what does it really mean? Well, if you think about it for a moment, the place where people usually want to integrate applications is at the database tables. For example, a database of users contains nothing more than name, login, and password. But what if we want to integrate a user authentication application with a billing application? The billing application looks for a different set of fields, such as account balance, payment due date, etc. and is not interested in the user's password. The obvious approach is to add more fields to the database table or create another table and join the two. A more flexible approach, however, is to abstract out the database table access, making the storage details irrelevant to the application. This has always been possible, but ZPatterns makes it easier. The other concepts in ZPatterns expand upon this model. I am still working on grasping them. ZPatterns also provides the "Plugins" architecture. Racks and specialists are derived from the plugins classes. I see plugins as being a concept that could be used by product authors who don't have a use for racks and specialists. I wonder whether plugins ought to be made a part of standard Zope. Shane

6 10

package descriptions
by ethan mindlace fremen 07 Jul '00

07 Jul '00

Zopatistas! I have recently changed the product page at http://www.zope.org/Products . If you would be so kind as to change your product description so that the first line contains a meaningful description of your product in plain text, I would appreciate it. Thanks, ethan mindlace fremen Zopatista Community Liason

7 8

Product Data Storage
by Andy Dawkins 06 Jul '00

06 Jul '00

I have an interesting issue which I don't think has been raised. But instead of solving the issue myself I thought I would share it with you guys/gals and see what you think. I am currently working on a Zope MailIn product, which allows you to send emails directly in to Zope. Version 0.1 can be found at: http://www.zope.org/Members/NIP/ZMailIn In version 0.2 I plan to have a ZMailIn python product which will handle the Zope side of things and behave a bit like a client. For example you could add a ZMailIn product instance in to Zope and configure it to receive all emails for bob(a)bobscompany.com and provide a method to execute upon mail arrival. This is great and you could have n ZMailIn product instances throughout your Zope site and in any position. When email arrives I need to find all the ZMailIn instances within the ZODB and hand the email to the correct one. I have decided AGAINST searching the ZODB for instances of ZMailIn because that is just too scary, hideously inefficient and I don't want to go there. Instead I thought of keeping an up-to-date list of where all the current instances where held. My original idea was to get the ZMailIn product to write a file in to the /lib/python/Products/ZMailIn directory, which shouldn't cause any problems that I can see. However, It had occurred to me that with the current growth of Zope it was going to become more popular that separate Zope instances of the same product may need to share some data. So my question is this: What are peoples opinions on storing shared product data? Where should it be placed? Should this ability be added to Zope as a standard? Thanks in advance. -Andy Dawkins (New Information Paradigms Ltd)

4 5

bug in zpatterns-0.4 ?
by Jephte CLAIN 04 Jul '00

04 Jul '00

hello, Rack.createItem (low level method) first calls Rack.getItem (higher level method) to check the existence of the item. This causes infinite loop in certain cases. It should (IMHO) call Rack.retrieveItem instead regards, jephte clain jclain(a)univ-reunion.fr

3 8

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev June 2000