Re: [Zope-dev] Possible 'bad' with Client.py and urllib
Dieter Maurer wrote:
Chris Withers writes:
urllib Client block Zope
That would suggest a bug in Python's socket implementation:
its "makefile().read" method would not release the global
interpreter lock.
Do you think this is likely? If so, where would I go to report it, or maybe it's
perhaps already fixed in Python 2.0?
That said, this problem only started manifesting itself when the target of the
urlopen or Client.get was a Python Script. It had been working fine before when
the target was DTML Method.
What with the Byte Code hacks, etc, in Python Scripts, I wonder if that isn't
maybe the problem.
Has anyone got any ideas how I'd go about inestigating this?
cheers,
Chris
___
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] ZCatalog stuff
"R. David Murray" wrote: On Thu, 22 Feb 2001, Chris Withers wrote: Apart from that, any ideas how I'd search for a record where the indexed attribute is blank or the secondary sort stuff? Somebody contributed a patch for the secondary sort stuff a while back. Whether it still works with 2.3.0 is a good question. Any idea where I'd find that? I may need to give it a go... I also remember a *long* time ago (back when I was first starting with zope about a year ago) someone posting a method for picking up all the records in a catalog with a blank value for a field. How you'd find it in the mail archives, though, I have no clue, nor do I remember what the method involved. Likewise with this. The only solution I can think of at the moment is to have a seperate 'x_is_blank' index that set to 'not x', but that seems terribly inefficient to me :-S Any ideas gratefully recieved :-) Chris ___ 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] How to build indexes in the MemberCatalog of Membership Component?
Bill Anderson wrote: I use, and recommend the use of a ZPattern trigger. You can get it by downloading the DataSkins product. This way, whenever a member is modified, it automatially updates/creates it's entry in the catalog. Just be sure to specify MemberCatalog :) To expand on what Bill said: Stick this in a SkinScript method in your Membership folder, on the Data Plug-Ins tab of err... Users perhaps? User Sources? You should be able to work it out. (I don't have a live LoginManager to hand right now.) WHEN OBJECT ADDED CALL MemberCatalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/')) WHEN OBJECT DELETED CALL MemberCatalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')) WHEN OBJECT CHANGED CALL MemberCatalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')), MemberCatalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/')) -- 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 )
Re: [Zope-dev] catalog object owners?
Chris McDonough wrote: Aha? So if I specify a field index of, get_parent_node_id, which is a function call on all objects that are to be indexed, this would index the returned value? If so, how long has this been available? As long as the catalog has been around, AFAICT... This is one of its very most basic features. And one of it's most endearing :-) Chris ___ 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] Search Features and Zope Directions Road Map
p.d. Right now I'm quite interested at the technology of searching and finding non structured content, in order to compose structured documents. For example, the guys at Vignette (StoryServer) say that its customers don't need to keyword anything in order to have a "related content" section. After the writer finishes a story, Take a look at http://beta.osdigger.com. It is a mailing list search engine I was working on about a year ago, unfortunately I've not had the time to work on it since. It is designed to scale to doing full text ranked searches on millions of email messages in under a couple of seconds on a single machine (currently PII-300). It has a 'two-step' search feature which brings back related terms to ones you put in (usually :). eg. type in 'scsi controller' and chances are it will return adaptec amongst the list of other terms. The idea is to prompt the user to be more specific with their search. I would love to take more time to work on it again, and would like to be able to access it from withing Zope and use it to catalog arbitary Zope object like ZCatalog does. -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ 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] ZPatterns: commitSubtransaction() gives AttributeError on commit_sub
Dear Brian, req = context.REQUEST context.propertysheets.info.manage_changeProperties(longdesc=req.f orm['longdesc']) context.commitSubtransaction() req.RESPONSE.redirect(req['URL1']+'/edit_longdescForm') context is a DataSkin instance. When I submit the form, I get an Attribute Error on commit_sub (traceback below in case it helps anyone). As far as I can see from the ZPattern's source, I'm making the call correctly and it is an appropriate call. Any clues? This is Zope 2.3.1b1 and Steve's convenience release of ZPatterns. --RDM Traceback: AttributeError: (see above) I believe we've tracked this down and fixed it properly - the fix will be in 2.3.1 b2, but I've a attached a copy of the updated Transaction.py that you can drop into lib/python/ZODB, then restart. It would be great if you get a chance to confirm the fix and let me know how it goes... Note I've cc'ed a few other folks who have run into this specific problem - if any of you can spare a few moments to verify the fix and let me know if you still see any problems, I'd really appreciate it. That sorted everything for me. Thanks very much. Just for info, I'm still using Zope 2.2.5 and just dropping the updated Transaction.py into that worked fine. Thanks again. Cheers, Ian ___ 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] More ZCatalog Stuff.
I am assuming that the code you provided goes into a
manage_addCustomIndex method that is part of a CustomIndex
Python Product.
hehehehe, nothing so general-purpose as that ;-)
You will need to implement a subclass derived from one of
the standard
indexes to provide your custom indexing policy, whatever that is.
Can you provide the code for your custom KeywordIndex, so I
have a starting point? I realize yours subclasses a
KeywordIndex, and I probably need to subclass a TextIndex,
but it would still probably help. I can integrate and hack
on other peoples code better than I can write my own from
scratch.
from SearchIndex.UnKeywordIndex import UnKeywordIndex, MV, intSet
from types import ListType, TupleType
class UnTrackingIndex(UnKeywordIndex):
meta_type = 'Tracking Properties Index'
"""Like a Keyword Index, only it indexes tracking properties
"""
def __init__(self,question):
id = 'tracking_'+unicode(question).encode('unicode-escape')
self.question = question
UnKeywordIndex.__init__(self,id)
def index_object(self, i, obj, threshold=None):
""" index an object 'obj' with integer id 'i'"""
index = self._index
unindex = self._unindex
try:
kws = obj.tracking_answers(self.question)
if type(kws) not in [type([]),type(())]:
raise ValueError('Indexing a tracking property set of
inappropriate type %r' % type(kws))
except:
kws = (MV,)
# index each item in the sequence
for kw in kws:
set = index.get(kw)
if set is None:
index[kw] = set = intSet()
set.insert(i)
unindex[i] = tuple(kws)
self._index = index
self._unindex = unindex
return 1
___
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] _getOb or __getattr__?
Hi, I need a product with custom attribute getting code and so looked to the BTreeFolder product for inspiration. It implements both __getattr__ and _getOb which appear to do roughly the same thing. What's the difference? Shane hints that __getattr__ is slower but allows acquisiton. Why is that? TIA, Chris ___ 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] Search Features and Zope Directions Road Map
after reading the Directions Roadmap from DC, I was surprised that a substantial improvement of the searching features of Zope, wasn't mentioned as a major concern. snip Moreover, everybody uses more Google to look for everything, bypassing windows, doors, and portals!. Why? Because it's terribly smart (not mentioning its 6,000 Linux boxes, by the way), and because there's no need to follow the highly-engineered information architecture of a web site, if there's a trustful shorcut to the relevant content!. So, if I'd have to mention one big feature improvement to Zope, I wouldn't doubt: "search engine". snip On the other hand, Fast, from Norway, already have a nice multimedia search engine, from regular, non-structured, spidered web pages. Can we do that "structuring the unstructured" thing within Zope? You have posed an important question (and, probably some answers), that hopefully I can clarify. One of the all-important points of the Zope directions document is that our number one goal is to make it wildly easier for _developers_ to create and deploy quality components. Why is this so important? Your questions in this email is why that is so important. You are very interested in high-quality search capabilities, and others certainly are as well. Some other folks care more about E-Commerce, or Corba integration, or communication with Java components. The problem, of course, is that even if DC devoted every single person here to creating the "best search engine" (which we couldn't do for very long - we'd soon be gone), we would still be hard pressed to even come close to making everybody happy or being competitive with every other search engine vendor out there. And the reality is that it is not our goal in life to be a better Google than Google. Multiply that by the number of things people want (ECommerce, Corba, et. al.), and the problem is quite clear - *DC cannot possibly provide the best, most featureful and competitive component for every problem*. The *solution* to this problem is what is outlined in the Zope directions document - dramatically lowering the bar of development to allow a thriving marketplace of robust components (that are *not* written by DC), allows interested parties to write (or better yet, reuse) "the best x component" for their purposes. In the future, Zope may come with "some batteries included", in that a Zope distribution may include the latest versions of the most popular and widely used components. But we hope that the idea of "The ZCatalog" (for instance) will fall by the wayside. Zope may still come with a search component such as ZCatalog that is useful for certain tasks and perhaps as a learningtool, but it will not be an infinitely-scalable infinitely-featureful thing that everyone uses for every problem. The hope is that when you outgrow ZCatalog you can move on to other search components particularly suited to your problem domain. If you scale beyond what ZC can handle, maybe you move up to some VeritySearch component that makes use of existing software. Even now, with the current pain level of component development, building a VeritySearch component would probably take considerably less time than building and maintaining equivalent features into "the ZCatalog". This is the future - the way that Zope will succeed is by being the best framework and component integration platform for the Web, not by trying to compete with verticals like search engine vendors on feature points. "Use the right tool for the job" is something we have always believed in, and providing a platform that will allow you to use and integrate the most appropriate tools will be our focus going forward. That is why "substantial improvement of searching features" is not on the futures roadmap - we do not want to provide the best search engine for every task. We want to make it easy for you to build or integrate the "right" search solution for your task. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ 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] _getOb or __getattr__?
Jeffrey P Shell wrote: _getOb and _setOb are for placing subobjects somewhere besides attributes (which is the default implementation). When would __getattr__ be used then? cheers, Chris ___ 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] _getOb or __getattr__?
Jeffrey P Shell wrote: _getOb and _setOb are for placing subobjects somewhere besides attributes (which is the default implementation). _getOb and friends are the default protocol that *SHOULD* be used by systems that change subobjects (ie - copy and paste). Sorry, just thought of another coupla questions: If x is an instance of my class, then: If I do x.a = 1, is _setOb called? If I do print x.a, is _getOb called? cheers, Chris ___ 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] _getOb or __getattr__?
"Chris Withers" [EMAIL PROTECTED] wrote: Jeffrey P Shell wrote: _getOb and _setOb are for placing subobjects somewhere besides attributes (which is the default implementation). When would __getattr__ be used then? In what context? You could wire __getattr__ to call into _getOb (and probably __getitem__ too, since that's also used in traversal and as a way of getting non-Pythonic ID'd objects). def __getattr__(self, attr): return self._getOb(attr) Until very recently, __getattr__ on persistent objects was like playing with nuclear fire. But now, I *believe* it behaves properly, which means __getattr__ gets called when it receives an unknown name. How that affects Acquisition, I don't know. ___ 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] _getOb or __getattr__?
Sorry, just thought of another coupla questions: If x is an instance of my class, then: If I do x.a = 1, is _setOb called? If I do print x.a, is _getOb called? No in either case. _setOb shouldn't be used directly in the current ObjectManger implementation. It doesn't populate the _objects list of the object manager on which it was called (your object won't show up). Instead, _setObject should be called. ___ 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] RE: [Zope] Zope Good/Bad News Article
Just read your article (http://www.pault.com/zope.html) and really enjoyed it (besides comparing Java to Macs... yikes!). I agree that DC needs to really work with Zope Product Developers and help them as much as possible. Have you looked at the Zope Directions document recently posted on dev.zope.org? http://dev.zope.org/Resources/ZopeDirections.html Dramatically lowering the bar for developers to create quality components is our number one priority going forward. It will be evolutionary and not happen all at once, but it will be happening. DC should encourage and then force developers to be a bit better about documentation. I have seen product developers put up a new product with the full amount of documentation about it being "here it is... have fun." This certainly does not help all of those people who want to install and use Zope products. DC can encourage better product development and documentation by doing simple things such as T-shirt contest for best product documentation, tip, how-to and all the rest. One idea we've kicked around is to make the eventual "components area" on zope.org such that component users can provide some +1 -1 type feedback that is incorporated into the way that components are listed on the site. This would let the most popular / best components appear at the top of listings etc. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ 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] _getOb or __getattr__?
Chris McDonough wrote: Sorry, just thought of another coupla questions: If x is an instance of my class, then: If I do x.a = 1, is _setOb called? If I do print x.a, is _getOb called? No in either case. _setOb shouldn't be used directly in the current ObjectManger implementation. It doesn't populate the _objects list of the object manager on which it was called (your object won't show up). Instead, _setObject should be called. well, thankfully, I'm not going near __setattr__, _setOb or _setObject :-) On the setting side, only __setitem__ is getting meddled with, and I'm guessing there's not gotachas there? Anyway, using these methods: # attribute - based traversal stuff def _getOb(self, name, default=_marker): print '_getOb:',name try: return higher_getOb(self,name) except: import sys print 'type:',sys.exc_type print 'value:',sys.exc_value raise AttributeError,name def __getattr__(self,name,higher_getattr=higher_getattr): #print '__getattr__:',name try: return higher_getattr(self,name) except AttributeError: import sys #print 'type:',sys.exc_type #print 'value:',sys.exc_value raise AttributeError,name def __getitem__(self,name,higher_getitem=higher_getitem): print '__getitem__:',name try: return higher_getitem(self,name) except KeyError: import sys #print 'type:',sys.exc_type #print 'value:',sys.exc_value raise KeyError,name ...it would appear that unrestrictedTraverse first tries to use getattr and then tries to use getitem to get a name. That much I can veryify from the code ;-) However, it would appear that somewhere in a __getitem__ as implemented by ZCatalog, _getOb ends up getting called. Which is a little confusing :-S I think I know when the __get methods get called; same as normal python right? But when, why, how and what by does _getOb and/org _getObject and/or anything else I might be interested about in this space get called? ;-) Thanks loads for the help so far, Chris ___ 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] Re: [Zope] Search Features and Zope Directions Road Map
Please do NOT cross post. -Michel On Mon, 26 Feb 2001, Ausum wrote: Zope is a great application server, the same as its soon to be released Content Management Framework, because of its bet on Python, everybody say it. Nevertheless, after reading the Directions Roadmap from DC, I was surprised that a substantial improvement of the searching features of Zope, wasn't mentioned as a major concern. For a new Zope enthusiast like me, it is a kind of addiction to arrange and administer content while taking the learning curve. Almost everybody in this list with a non-programming background might've experimented this. But when I arrived to the search features of ZCatalog, I got mixed feelings. (Right now I'm stuck on this OR indexes searching :) ) The fact is that - according to my strong belief - everybody uses more Google to look for Zope Site's content than Zope's own Zcatalog's search engine. Moreover, everybody uses more Google to look for everything, bypassing windows, doors, and portals!. Why? Because it's terribly smart (not mentioning its 6,000 Linux boxes, by the way), and because there's no need to follow the highly-engineered information architecture of a web site, if there's a trustful shorcut to the relevant content!. So, if I'd have to mention one big feature improvement to Zope, I wouldn't doubt: "search engine". I just wanted to point on this subject. I know Zope isn't about spidering and retrieving, but it should have "Greater Search Capabilities" as a title, within that roadmap. :) Ausum p.d. Right now I'm quite interested at the technology of searching and finding non structured content, in order to compose structured documents. For example, the guys at Vignette (StoryServer) say that its customers don't need to keyword anything in order to have a "related content" section. After the writer finishes a story, (possibly while) a routine by Autonomy (www.autonomy.com) reads the document and finds out what the document is about, and so it triggers a search for related content within the site, without the need of intervention by the writer. (For the curious, Autonomy has published a personal version of its software. It's called Kenjin (www.kenjin.com) ). On the other hand, Fast, from Norway, already have a nice multimedia search engine, from regular, non-structured, spidered web pages. Can we do that "structuring the unstructured" thing within Zope? ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ___ 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] ZClass propertysheets
Hi! I am just wondering if it's possible to get hold of the properties of a propertysheet of a ZClass without instanciating it. So when instanciating I would just do map=object.propertysheets[1].propertyMap() and get all information of my ZClass instance object. So is this also possible on the class definition? (actually I would assume it is stored somewhere as I can edit it via the management interface. I just didn't manage to get it from the source code..) (next question might be how to get the class when only having a meta type or the path to it.. but I think I will just search the Zope source..) kind regards, Christian -- COM.lounge http://comlounge.net/ communication design [EMAIL PROTECTED] ___ 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] Zope Development Roadmap Components
While reading the Zope Development Roadmap about components I had a question. It says: """Components will be edited via the filesystem as .py files. Components will probably be checked into and out of Zope via a CVS like facility. Components can be tested locally without checking them into Zope.""" What does this say about developing components with Py/Perl Scripts? It looks to be closer to the current Python Products. I like the idea above but just trying to understand the big picture about the future. Any enlightenment appreciated. Jimmie Houchin ___ 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] _getOb or __getattr__?
Chris Withers wrote: Hi, I need a product with custom attribute getting code and so looked to the BTreeFolder product for inspiration. It implements both __getattr__ and _getOb which appear to do roughly the same thing. What's the difference? _getOb() is part of the ObjectManager interface. If you want to store objects in your special ObjectManager in a special way, you override _getOb(), _setOb(), and _delOb(). (I didn't check the spelling--see ObjectManager.py) However, if you store objects in your ObjectManager in a different way than using setattr(self, name, value), acquisition won't find your subobjects because acquisition only looks at object attributes. It doesn't know anything about _getOb(). (And it's not a good idea to teach it to use _getOb(); think what it would be like if a Xeon ran like a 386...) Overriding __getattr__() lets you make acquisition work again. However, as Jeffrey said, until a few months ago it was forbidden. Then Jim fixed it. Now it's used extensively by BTreeFolders, Transparent Folders, and even the CMF. However, every time the acquisition machinery calls a __getattr__() you get a performance hit in the range of a few microseconds. But the products I listed try hard to minimize that impact, so it's not enough of an issue to warrant a C implementation. BTreeFolder.py provides a base class that doesn't have __getattr__(). You can use that if you think __getattr__() is slowing down your site. The derived class is what most people use because it provides the full functionality. Shane ___ 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] RE: [Zope] Zope Good/Bad News Article
Brian Lloyd wrote: DC should encourage and then force developers to be a bit better about documentation. I have seen product developers put up a new product with the full amount of documentation about it being "here it is... have fun." This certainly does not help all of those people who want to install and use Zope products. DC can encourage better product development and documentation by doing simple things such as T-shirt contest for best product documentation, tip, how-to and all the rest. One idea we've kicked around is to make the eventual "components area" on zope.org such that component users can provide some +1 -1 type feedback that is incorporated into the way that components are listed on the site. This would let the most popular / best components appear at the top of listings etc. The T-shirt idea has a lot of merit, though. It would be more fun. :-) (and thus more encouraging) Shane ___ 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] Zope Development Roadmap Components
On Tue, 27 Feb 2001, Jimmie Houchin wrote: While reading the Zope Development Roadmap about components I had a question. It says: """Components will be edited via the filesystem as .py files. Components will probably be checked into and out of Zope via a CVS like facility. Components can be tested locally without checking them into Zope.""" What does this say about developing components with Py/Perl Scripts? It looks to be closer to the current Python Products. Yes. We have thought a bit about "composite components" and "persistent modules" and stuff like that, but we only went so far into elaboration when we realized that it required lots, and lots of thought and effort. The current component effort is much simpler, a component is: an object with an interface. If this is a ZClass with Perl-based script methods, then so be it, but we haven't thought far enough into what ZClasses really are to start thinking about giving them interfaces. Is this sort of what you're asking? -Michel ___ 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] Zope Development Roadmap Components
Yes this is what I was looking for and somewhat expecting. I can understand the challenge in getting ZClass, Py/Perl Script, "composite components" done right. In fact to me they could easily make things more complex. Potentially more complex process and more complex machinery to handle it. I would definitely be for a simpler model of components which are just as describe .py files and an interface. I read somewhere that doing components right is/can be hard. The author wrote that component creation is done by the few for the many. There will be fewer component authors and more component users and integrators. I agree with his assessment. I think what will make it easier for component authors will be well a defined API. This appears to me what y'all are doing. If I understand correctly. Thanks. Jimmie Houchin Michel Pelletier wrote: On Tue, 27 Feb 2001, Jimmie Houchin wrote: While reading the Zope Development Roadmap about components I had a question. It says: """Components will be edited via the filesystem as .py files. Components will probably be checked into and out of Zope via a CVS like facility. Components can be tested locally without checking them into Zope.""" What does this say about developing components with Py/Perl Scripts? It looks to be closer to the current Python Products. Yes. We have thought a bit about "composite components" and "persistent modules" and stuff like that, but we only went so far into elaboration when we realized that it required lots, and lots of thought and effort. The current component effort is much simpler, a component is: an object with an interface. If this is a ZClass with Perl-based script methods, then so be it, but we haven't thought far enough into what ZClasses really are to start thinking about giving them interfaces. Is this sort of what you're asking? -Michel ___ 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] CopySupport issues
These comments are against the CVS of about a week ago. I can't get to the CVS to update at the moment - the connection times out. Is there a reason why the manage_main call at the end of manage_copyObjects and manage_cutObjects in CopySupport gets called as self.manage_main(REQUEST) instead of self.manage_main(self, REQUEST)? Using the first form, we found that the manage_main call was dying because it couldn't acquire various attributes and methods it needed (eg, manage_page_header :). The second form just makes sense... In the Copy operation of manage_pasteObjects, the manage_afterClone is called before the object is added to its container. We'd much prefer the object to be both added to the container and re-got so it the manage_afterClone call may make use of acquired information. This is of use specifically for us so that the object may determine its new URL and catalog itself with our (Z)Catalog. Interestingly, a call to absolute_url() on the object breaks because self.REQUEST is 'Special Object Used to Force Acquisition' (yes, a string). Buggered if I know where that came from (actually, I know it originates in Acquisition.c, but that's a scary, scary place :) Richard -- Richard Jones [EMAIL PROTECTED] Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) ___ 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 )
